Outlevo shipped a developer sandbox with fake companies and contacts, an MCP server, and the TypeScript SDK and components on 2026-10-18 [[1]](#sources). The same day, Public API v1 arrived with scoped test and live keys, idempotency keys, rate limits and signed webhooks [[2]](#sources).
This post covers what each piece does, what stays the same when you move from test to live, and a sensible order for trying it. If you want the full list of changes for the week, see What changed in Outlevo, week 43 2026.
What changed
Three things arrived together, alongside Public API v1 [[2]](#sources).
The sandbox. Test keys run against a sandbox with fake companies and contacts, and they are not charged [[3]](#sources). You can build against realistic shapes of data without touching a real account list or spending credits.
The MCP server. Outlevo now offers an MCP server alongside the REST API and the SDK [[3]](#sources). The release notes list it without further detail, so check the developer hub for what it exposes before you plan around it.
The TypeScript SDK and components. The SDK is the TypeScript way to call the API from your own project [[3]](#sources). The release also ships components [[1]](#sources). Again, the developer hub is the place to see exactly what is included.
Underneath all three is the public API. Everything in the app is available in the REST API [[3]](#sources). The API reference lists 96 paths [[4]](#sources). The resources include campaigns, companies, contacts, policies, webhooks, ledger, suppressions and usage [[4]](#sources).
That last point matters. If you can do something in the app, you can do it in code. You do not need to wait for a feature to be added to the API first.
Test keys and live keys
API v1 uses scoped test and live keys [[2]](#sources). The part the sources spell out is the test key.
- A test key talks to the sandbox. The data is fake and nothing is charged [[3]](#sources).
- For live keys, the sources say only that they are the other half of the scoped pair. Check the developer hub for how they behave. Metered API calls quote their credit cost first and run only when confirmed [[3]](#sources).
Idempotency keys and rate limits are part of v1 as well [[2]](#sources). Idempotency keys let you retry a request without repeating its effect. That is useful when a network call times out and you are not sure whether it landed.
What does not change when you go live
The sandbox is a place to build. It does not change the rules that govern real outreach.
Nothing is sent outside a policy that a person approved [[5]](#sources). Policies set who can be contacted, on which channels, how often and with what budget [[5]](#sources). Every external action is checked against the approved policy before it runs, and recorded in a ledger [[5]](#sources).
So code you write against the API does not get a side door. If your script asks for an action that the approved policy does not allow, the check applies to it like any other action. Kill switches also still work. They pause a campaign, a channel or the whole workspace at once [[5]](#sources).
For a developer, this is a useful constraint, but it has limits. The approval layer limits what your code can do outside the policy. It does not check your logic. A bug could still trigger something the policy allows, so test your own code before it gets near a live workspace.
Security is the same story. Every customer table is protected by row-level security in the database [[6]](#sources). Personal data such as email addresses is encrypted at the field level [[6]](#sources). Staff support access is read-only, time-limited and logged [[6]](#sources). The details are on the security page.
Costs: what the sandbox saves you
Metered API calls quote their credit cost first and run only when confirmed [[3]](#sources). That is a good habit to build into your code from the start. Read the quote, check it against what you expected, then confirm.
The credit costs on the pricing page are:
- Contact discovery: 20 credits [[7]](#sources)
- Deep research: 30 credits [[7]](#sources)
- Email verification: 2 credits [[7]](#sources)
- Qualification: 8 credits [[7]](#sources)
- State change: 1 credit [[7]](#sources)
- Webhook delivered: 1 credit [[7]](#sources)
Plans start at USD 0 per month for Free [[7]](#sources). Builder is USD 29 per month with 320 credits a month [[7]](#sources). Growth is USD 149 per month with 1650 credits a month [[7]](#sources). Managed is priced per contract [[7]](#sources). Self-serve plans and credit top-ups go through Stripe Checkout, with sales tax [[8]](#sources).
Here is why the sandbox matters for budget. On Builder, 320 credits covers 40 qualifications at 8 credits each [[7]](#sources). Because metered calls wait for confirmation, the risk sits in code that confirms every quote automatically. If yours does, a bug in a loop could use those credits quickly. Running the loop against test keys first costs nothing [[3]](#sources).
Webhooks deserve a note too. Each delivered event costs 1 credit [[9]](#sources). If you subscribe to every event type, the cost adds up with volume. Events cover qualification, actions, handoffs, campaigns and usage [[9]](#sources). Subscribe only to the ones your code reads.
Webhook handling
If you build a receiver, three facts from the webhooks integration shape your design.
- Every delivery carries an HMAC signature [[9]](#sources). Verify it before you trust the payload.
- The replay window is 5 minutes [[9]](#sources). Reject deliveries that fall outside it.
- Retries run at 1 min, 5 min, 30 min, 2 h and 12 h [[9]](#sources). If your endpoint is down or returns an error, expect the same event again.
Because of the retries, make your handler safe to run twice for the same event. Decide how you will recognize a repeat, and check the API reference for what a delivery contains.
What to do
Here is an order that keeps risk low and cost at zero until you are ready.
1. Get a test key and make a first call. Use the sandbox with its fake companies and contacts [[3]](#sources). Start with a read, such as listing companies, so you see the data shape before you write anything.
2. Try the SDK. If your project is in TypeScript, use the SDK rather than hand-writing requests [[3]](#sources). Check the developer hub and the API reference for current details.
3. Try the MCP server if you work with tools that speak MCP. Read what it exposes on the developer hub first, and check how it authenticates. Do not connect it to a live workspace until you know what it can do.
4. Add a quote check to every metered call. Metered calls quote their cost and run only when confirmed [[3]](#sources). Make your code compare the quote with a ceiling you set, and stop if it is higher.
5. Build the webhook receiver. Verify the signature, enforce the 5-minute replay window, and handle repeated deliveries [[9]](#sources).
6. Read the policy resources. The API exposes policies, the ledger and suppressions [[4]](#sources). Knowing how your approved policy reads through the API helps you predict what a live action will be allowed to do.
7. Switch to a live key last. Move over only when the sandbox run behaves as you expect. Start with a small batch and watch the ledger, where every external action is recorded [[5]](#sources).
Summary
The sandbox lets you build without cost or real data. The MCP server and the TypeScript SDK give you two more ways in. API v1 adds scoped keys, idempotency keys, rate limits and signed webhooks. Live behavior still runs through an approved policy and a ledger. Start with a test key, check each quote, and go live when the sandbox run is clean.