Take the traffic. Keep your brand.
Our entire travel eSIM catalogue sits behind a single REST API. Buy at wholesale, sell at your price, and let us carry delivery, usage tracking and the refund workflow. Integration takes an afternoon.
Sandbox is free — run a full order end to end before you go live.
curl -X POST https://api.cotaesim.com/partner/v1/orders \
-H "Authorization: Bearer $COTA_TOKEN" \
-H "Idempotency-Key: PO-2026-00931" \
-H "Content-Type: application/json" \
-d '{ "planSlug": "fr-7d-1gb", "quantity": 2 }'
{
"orderId": "por_7f3a…",
"status": "completed",
"unitPriceCents": 499,
"requestedQuantity": 2,
"fulfilledCount": 2,
"esims": [
{ "esimId": "esim_1a2b…",
"lpa": "LPA:1$smdp.example.com$ABC-123-XYZ",
"universalLink": "https://esimsetup.apple.com/…",
"qrUrl": "/partner/v1/esims/esim_1a2b…/qr.png" }
]
}- SandboxSame endpoints as live, separate balance, test eSIMs
- One callOrder, delivery and QR in a single response
- WebhooksSigned events, eight-step retry ladder
- MobileTrack your orders from your phone
Four steps to your first sale
- 01
Get your credentials
We open a partner account for you. Exchange your
clientIdandclientSecretfor a 24-hour access token; tokens are opaque, so revocation is instant when you need it. - 02
Run it end to end in sandbox
Sandbox exposes the same endpoints, the same validation and the same error codes as live. The only differences: it draws on a separate balance and returns a test eSIM. Finish the integration without spending anything.
- 03
Request go-live
Ask for live access with one button in the portal. We enable the account, and your live credentials run through the same code path — the only thing you change is an environment variable.
- 04
Set up your account and sell
Two ways to trade: a prepaid balance, or an agreed credit limit. Either way every order is debited the moment it lands and every movement is written to an append-only ledger — you see what you spent without waiting for a month-end statement.
What the industry usually ships, and what we do instead
Most of the rows below are not first-week problems. They are the ones that hurt in month six. We solved them up front.
Test environment
Usual in the industrySandbox is either missing or behaves differently from live, so you debug the integration with real money.
COTA Partner APISandbox runs the same code path as live — same validation, same error codes, separate balance. Environment is part of the idempotency key, so a sandbox order can never replay onto a live request.
Partial delivery
Usual in the industryYou ordered ten, seven arrived. The money for the other three sits somewhere and you open a support ticket.
COTA Partner APIEvery undelivered unit is credited back to your balance inside the same transaction. The response reports
requestedQuantityandfulfilledCountseparately — no guessing.Retried requests
Usual in the industryA retry after a timeout creates a second order and a second charge.
COTA Partner APISend an
Idempotency-Keyand the same key returns the original response — never a second charge. When two requests race, one takes the lease and the other waits for it.Supplier failure
Usual in the industryWhen a supplier goes down the order simply fails, and nobody tells you why.
COTA Partner APIOn a definite rejection we fail over to a backup supplier automatically. When we never heard an answer we deliberately do NOT fail over and mark the line uncertain — buying the same unit twice costs you as much as it costs us.
Account visibility
Usual in the industryA month-end statement. Everything in between is a black box.
COTA Partner APIAn append-only ledger: every debit and credit, with its reason, readable immediately over
GET /ledger. Run prepaid or on an agreed credit limit — either way, live and sandbox accounts are kept apart.Event delivery
Usual in the industryPolling. You keep asking whether the order moved.
COTA Partner APISigned webhooks. Events are written inside the business transaction, so an order can never close with its notification lost. If we cannot reach you we retry across eight widening intervals, and you get an email if your endpoint is marked unhealthy.
Refunds
Usual in the industryEmail threads and an open-ended wait. You never know where the request stands.
COTA Partner APIOpen a refund REQUEST over the API and follow it with
GET /refunds. On approval the credit is written in the same transaction as the status change — "approved but not paid" is structurally impossible.Day-to-day oversight
Usual in the industryA desktop dashboard. Visibility ends when you leave the office.
COTA Partner APISign in to our mobile app with the same account, switch to the partner side, and watch your orders, eSIMs and ledger from your phone.
| Usual in the industry | COTA Partner API | |
|---|---|---|
| Test environment | Sandbox is either missing or behaves differently from live, so you debug the integration with real money. | Sandbox runs the same code path as live — same validation, same error codes, separate balance. Environment is part of the idempotency key, so a sandbox order can never replay onto a live request. |
| Partial delivery | You ordered ten, seven arrived. The money for the other three sits somewhere and you open a support ticket. | Every undelivered unit is credited back to your balance inside the same transaction. The response reports requestedQuantity and fulfilledCount separately — no guessing. |
| Retried requests | A retry after a timeout creates a second order and a second charge. | Send an Idempotency-Key and the same key returns the original response — never a second charge. When two requests race, one takes the lease and the other waits for it. |
| Supplier failure | When a supplier goes down the order simply fails, and nobody tells you why. | On a definite rejection we fail over to a backup supplier automatically. When we never heard an answer we deliberately do NOT fail over and mark the line uncertain — buying the same unit twice costs you as much as it costs us. |
| Account visibility | A month-end statement. Everything in between is a black box. | An append-only ledger: every debit and credit, with its reason, readable immediately over GET /ledger. Run prepaid or on an agreed credit limit — either way, live and sandbox accounts are kept apart. |
| Event delivery | Polling. You keep asking whether the order moved. | Signed webhooks. Events are written inside the business transaction, so an order can never close with its notification lost. If we cannot reach you we retry across eight widening intervals, and you get an email if your endpoint is marked unhealthy. |
| Refunds | Email threads and an open-ended wait. You never know where the request stands. | Open a refund REQUEST over the API and follow it with GET /refunds. On approval the credit is written in the same transaction as the status change — "approved but not paid" is structurally impossible. |
| Day-to-day oversight | A desktop dashboard. Visibility ends when you leave the office. | Sign in to our mobile app with the same account, switch to the partner side, and watch your orders, eSIMs and ledger from your phone. |
Your operation, in your pocket
The partner side is not desktop-only. Sign in to the COTA E-SIM app with your partner email and a "switch to partner account" option appears — your commercial view lives inside the same app.
Visible only to the people you invite
If your email is not a registered partner user, the app shows no partner button and no hint that one exists. For an ordinary customer nothing has changed.
Built for tracking, not selling
The mobile side is read-only on purpose: irreversible actions like placing an order or rotating credentials stay in the portal and the API. A mis-tap on a phone cannot spend money.
Identical on iOS and Android
The same screens in the same order on both platforms, so which phone your team carries never becomes a training difference.
Access opens by invitation
You invite a colleague by email, and the account only activates once that person confirms the link in their own inbox. A mistyped address opens no doors.
The same screens are on the web portal at partner.cotaesim.com — credentials, webhook settings and the go-live request live there.
A surface you can learn in an afternoon
Fewer than twenty endpoints in total: auth, catalogue, orders, eSIM lifecycle, account movements and webhooks. They all share one auth scheme, one error contract and one pagination shape — learn one and you have learned them all.
- Business errors return 422 with a machine-readable
code; 429 means rate limit and nothing else. - Order, delivery and QR arrive in a single response — no second call to wait on.
- Every endpoint behaves identically under sandbox and live credentials.
Every endpoint, its request and response schema and the full error catalogue live in the OpenAPI reference — a live document you can try calls against.
Open the full API referenceQuestions we get asked
Do I set the retail price?
Yes. We sell to you at wholesale; what you charge your customer is entirely your call. The amount you see in the catalogue is what we will charge you.
Can I sell under my own brand?
Yes — the API returns raw delivery data (LPA string, iOS universal link, QR image). You present it in your own app, your own email, your own design. Your customer never sees us.
Prepaid or on credit?
Both are available. On prepaid, what you top up is debited the moment an order lands, and once it runs out no order is created — so no debt accumulates behind your back. On credit, you may go below zero up to an agreed limit; which mode you are on is set on your account and GET /balance reports it back to you. Credit applies to the live account only — sandbox always runs on its own test balance. In either mode you are warned when you approach your threshold.
Are refunds automatic?
No, deliberately. POST /refunds only opens a REQUEST; our team decides. The moment it is approved, the credit is written to your ledger in the same transaction as the status change, and the reasoning is attached to the request.
Is sandbox really the same as live?
Same endpoints, same validation rules, same error codes, same webhook events. The differences: it draws on a separate balance and returns a test eSIM pointing at a test domain. No real line is provisioned.
Can several people from my team sign in?
Yes. Invite as many users as you like to the portal and the mobile side; sign-in is email plus a one-time code, with no passwords. Each invitation stays inactive until its owner confirms it from their own inbox.
What if I have no engineering team?
The portal does most of what the API does, on screen: catalogue, order history, eSIM details, ledger and refund requests. You can start trading without writing a line against the API.
Let us show you the catalogue
We will put together your price book and open your sandbox credentials so you can try the integration at your own pace. Going live is one button, whenever you are ready.