From a request to documentation somebody reads

Most API documentation is a lie by the third month. Not because anyone lied — because the docs live in one place and the requests live in another, and only one of them gets updated when a field changes.

Lodos closes that gap by generating documentation from the collection you are already testing against. That is the whole point of having the two modules next to each other, and it changes how you should organise the collection from day one.

Organise the collection for the docs, not for yourself

API Post/Get supports the full set of HTTP methods, request collections with folders, header and auth management, and a response viewer with syntax highlighting. The folder structure you choose becomes the structure of your documentation, so it is worth five minutes of thought.

Group by resource, not by task. A folder called users containing list, create, update and delete reads as documentation. A folder called onboarding flow containing three requests from three different resources reads as your personal scratchpad, because that is what it is.

Name requests as the API's own vocabulary. GET /users/:id is better than get one user, because someone reading the docs is trying to match what they see against the endpoint they are calling.

Environment variables are what makes it survive

This is the difference between a collection that lasts a year and one that stops working the first time staging moves.

Put every host, every token and every changing identifier into an environment variable. {{base_url}}/users/{{test_user_id}} is a request that works against local, staging and production by switching one dropdown. A request with https://staging-2.example.com baked into the URL is a request that breaks silently in three weeks and gets rewritten by whoever needs it next.

Pre-request scripts handle the case that trips people up most: an auth token that expires. Fetch it in a pre-request step and store it in an environment variable, and you stop pasting a fresh bearer token into eleven requests every morning.

Secrets, honestly

A collection is workspace-scoped, which means everyone with access to the workspace can see it — including the values in your environments.

Treat that as the design constraint it is. Development and staging credentials in the collection are fine and genuinely useful; a colleague picking up your work should not have to hunt for them. Production credentials are not fine. If a value would be a problem in a screenshot, it should not be in a shared environment.

The practical setup: one environment per stage, production kept deliberately incomplete so that running against it requires a conscious act rather than a wrong dropdown selection.

Turning it into documentation

API Documentation generates from the collection, then gives you a rich text editor on top, version management, code snippet generation, PDF export and shareable links.

The generated part covers what the endpoint is and what it takes. What it cannot know is why anyone would call it — and that is the part readers actually need. So the pattern that works:

1. Generate from the collection. Do not hand-write the endpoint list; it will drift.
2. Add a short paragraph per resource explaining what it is for and when you would use it.
3. Document the errors. Not the 200 — the 409 that means the email is taken, and what the client should do about it.
4. Publish a share link rather than exporting a PDF, unless someone specifically needs a file. A link stays current; a PDF is a photograph of a moment.

Version management matters when you have external consumers. Cut a version at the point where someone starts building against it, so that when you change something, there is still a document describing what they built against.

The 130 small things

Worth knowing because it saves a browser tab: the Tools module has 130-plus utilities — JSON and XML formatters, encoders, converters, hash generators. They run entirely in your browser, nothing is uploaded, and they cost no tokens.

That last detail matters more than it sounds. Pasting a payload into a random online JSON formatter means pasting your data onto someone else's server. If the payload has a customer's details in it, that is a small incident nobody will ever notice. The local tool removes the temptation.