Use a test key
Apk_test_ key returns the same data as a live key, has lower rate limits, and is not billed. Use it for development, CI and the playground on this site. Keep live keys for production.
There is no separate sandbox: test keys read the real, current registers. Write tests that hold however the data changes.
Pick small registers
The Andorran (AD) and Albanian (AL) registers are small, so searches over them are fast and their results are easy to check by hand. They are a good default scope for integration tests:
tm_AD_2376e41e-3d24-57e3-af6f-6a176f9985ba exists and has registration number 48000, not that a search returns exactly 17 records.
Contract tests
/v1/openapi.json is the machine-readable contract: OpenAPI 3.1, with every parameter, response and error. Validate the responses your code depends on against it, for example with Schemathesis or an OpenAPI validator in your test framework. Allow additional properties and unknown enumeration values, as v1 adds them over time (see Versioning).
Exercise your error handling
You can produce most errors deliberately with a test key:
Do not test authentication failures or rate limits against the live API in a loop. Twenty lookups of unknown keys within a minute block your IP address for five minutes, and deliberately exhausting a rate limit slows your other tests. Simulate 401, 429 and 503 responses with a mock instead, using the bodies and headers shown in the errors reference.
Smoke checks
GET /v1/health needs no key and is not counted. It returns 200 when the API can reach its data stores, and 503 otherwise. Use it in deployment smoke checks and status pages, not as a reason to stop your own service: a 503 there means requests may fail for a while, and your error handling covers that.