API request logs
that answer what actually happened
Every call against your account, with the request, the response, the key that made it and how long it took. Queryable through the API, not exported nightly into somewhere else.
Sandbox profiles are simulated and cost nothing. No card, no commitment.
WHEN SOMETHING BREAKS
The first question is always what was actually sent.
And the usual answer is that nobody kept it.
Find the call
By key, by outcome, by window. The log is queryable rather than something to be exported.
See both halves
The request as it arrived and the response as it left, not a summary of either.
Locate the fault
One error shape, with the parameter at fault named, settles most arguments immediately.
Change one thing
And re-run the same call from the explorer to confirm it.
A log you cannot query at the moment you need it is an archive, not a log.
WHO IT IS FOR
For the hour after a customer reports something
Debugging an integration across two organisations usually starts with each side asking the other what it sent. This removes that conversation.
The record is not the argument. Make a few sandbox calls and read them back today, at no cost.
WHAT YOU GET
A record you can interrogate, not one you have to retrieve
What was sent, what came back, which key was used and how long it took, all of it filtered, paged and readable through the same API as everything else.
- Coverage
- Every call against the account, in both environments, whichever route it came by.
- Both halves
- The request as received and the response as sent, rather than a status line.
- Attribution
- Which key made the call, so a misbehaving integration is identifiable rather than suspected.
- Timing
- How long each call took, which is where a slow integration is usually found.
- Paging
- Cursor rather than offset, so paging a busy log does not skip or repeat entries.
- Keys
- Filter by key. Test and live are separate, so a noisy pipeline does not bury a production fault.
- Retries
- An idempotent retry is visible as a retry, so a repeated call is not mistaken for a duplicate order.
- Errors
- One shape everywhere: a type, a code, a message, the parameter at fault and a link. Never a bare 500 with a stack trace.
- Reference
- One published OpenAPI specification. The server validates against it, the SDKs are generated from it and the sandbox mocks from it.
WORKS WITH
Switch on the next one the same way
Nothing new to sign and nothing new to integrate. The same call with a different noun.
QUESTIONS
Logs on Telyne
What is recorded?
Every call against the account, in both environments: the request as it arrived, the response as it left, the key that made it and how long it took.
Do I have to export it somewhere to use it?
No. The log is queryable through the API, filtered by key, outcome and window. A log you can only retrieve in bulk at the end of the day is an archive rather than a log.
Can I tell which key made a call?
Yes. Every entry is attributed to the key that made it, which is how a misbehaving integration is identified rather than suspected.
Why cursor pagination here?
Because a busy log is being written to while you page it, and offset pagination skips or repeats entries under exactly those conditions.
Are test and live logs separate?
They are filterable apart, so a noisy pipeline in test does not bury a production fault. Both are recorded the same way.
Read your own calls back before anything goes wrong
No approval step and nothing to sign. The sandbox is open now, and production access opens in the order requests arrive.
One email at launch. Nothing else, and unsubscribe in one click.
We send a link to confirm the address. Unconfirmed addresses are deleted after 30 days.
Complex requirement or an existing estate to move? Talk to us.