Context
Qive ingests and structures fiscal documents for companies. The platform is consumed programmatically (by ERPs, accounting software and partner systems), so the API is a product surface, not an internal detail. Integrators need a place that answers three questions: what can I call, how do I authenticate, and does it actually work.
Problem
- Without executable documentation, "does this endpoint really work?" is answered late, after the integrator has already written code.
- Authentication and error handling are where integrations break first, and where a text-only reference helps least.
- Every unanswered question becomes a support ticket instead of a self-service answer.
My responsibility
I built the developer portal: the documentation interface and the interactive API playground.
What is published
- A public portal at developers.qive.com.br, in Portuguese, aimed at Brazilian integrators.
- A documentation area under
/docs. - An interactive playground that executes API calls from the browser and shows the response: the part that turns a reference into something an integrator can trust.
- Runtime configuration injected into the page (
window.__ENV), so tracking and environment endpoints are not baked into the bundle at build time.
How it was built
- Next.js (App Router) with a Turbopack build: a server-rendered shell plus a client-side application.
- Environment configuration is injected at runtime instead of compiled into the bundle, so the same artifact can run against different environments.
Result
A public portal in production that documents the API and lets an integrator try it before committing to an implementation, turning a recurring support question into a self-service answer. The impact lives in the integration experience: the first questions get answered before anyone opens a ticket.
What I learned
- A playground is a product decision, not a documentation feature: it moves the "does it work?" question to the cheapest possible moment.
- Documentation that runs is also a test of the API: if a request fails in the playground, the integrator finds out before writing any code.
- Developer-facing products have their own UX rules: an integrator wants the request, the response and the error, fast, without a signup wall in the way.