fc_test_…) and every endpoint works exactly as in live mode, with the same requests, responses,
statuses and webhooks.
What test mode can’t know is what CAC would decide. So you choose: add a simulate query
parameter and the registration takes that path. Live keys ignore simulate, so you can leave it in
code paths you share between modes (though you’ll usually only send it from tests).
The only difference you’ll see when you switch to a live key is that
simulate stops having an
effect, because real outcomes now come from CAC.Name checks
Withoutsimulate, test mode applies CAC’s naming rules (no single-word names, no restricted
words, a qualifier such as VENTURES at the end) and otherwise says the name is available. It never
searches the real registry. To get any other answer, pass simulate:
Response
Documents
POST /v1/registrations/{id}/documents?simulate=rejected makes the upload come back
rejected, with a reason, and fires document.rejected. Without it, uploads are verified.
What happens after submit
Passsimulate (and simulate_query) when you submit. They decide what happens after payment.
simulate_query is a comma-separated list of what CAC asks about. Each item uses CAC’s own wording:
Skipping the wait
Test helpers move a registration on immediately. They exist only in test mode.
Anything else is
409 invalid_state. Answering a query is never a shortcut: fix the fields and
submit, as in live mode (Handling CAC queries). The Simulate menu on a
registration in the dashboard does the same as advance.
Test data
Test mode checks values exactly as live mode does: real-looking NINs (11 digits), Nigerian postcodes (6 digits), adult proprietors, aline_of_business from the list. Use made-up people;
test-mode data is never sent anywhere.