Questions about requests, response formats, and upstream behavior.
Common answers for teams integrating the Angola-focused ORB3X Utils API surface.
Requests
What does this site document?
The site documents the current ORB3X Utils API surface, including validation, phone, geo, calendar, finance, salary, time, documents, and the legacy NIF, translation, and exchange routes.
Do all routes return JSON?
Most routes do, but the document endpoints return PDF files on success. Error responses still use JSON.
Which routes expect a request body?
The document endpoints and `/api/translate` expect JSON bodies. Most of the other routes use query parameters.
Caching and errors
Are responses cached?
No. The route handlers return `Cache-Control: no-store` because the data comes from live upstream services.
What happens when an upstream provider times out?
The route returns a timeout-related error code so your client can decide whether to retry or show a fallback state.
How should retries be handled?
Retry only when the response indicates an upstream timeout or upstream availability problem. Do not retry validation errors.
Route behavior
How current is the NIF data?
The route returns whatever the public Angolan tax portal exposes at request time.
Which languages can the translation route accept?
It accepts the language codes supported by the underlying translate endpoint, subject to the validation rules described in the docs.
Can the currency route return converted totals?
Yes. Add an `amount` query parameter to receive both `unitRates` and `convertedRates` in the same response.
Using the output
Should I store the returned data?
That depends on your own product requirements. If a response affects an audit or business decision, store it together with your own context.
Where should I look first when debugging?
Start with the API reference for shared status codes, then move to the dedicated route page for endpoint-specific request and response details.
Which pages should stay open while integrating?
The getting started page, API reference, and examples page cover most integration work.
Keep the reference pages close while integrating.
The getting started guide covers shared behavior first, then the route pages cover the request and response details.