Forem: Dhruba Patra

OAuth in Voiden

Dhruba Patra — Thu, 12 Mar 2026 12:35:36 +0000

In the world of API design, authentication is not a detail - it's architecture.

Yet, in many API clients, authentication is abstracted away, treated as a quiet dropdown or a hidden side panel. While this works, it can hide crucial mechanisms, leading to confusion, duplication, and fragile configurations that are difficult to manage as a system evolves.

Voiden was built to challenge this model. Because Voiden is fundamentally based on composable blocks, authentication is not a hidden configuration. It is a first-class, reusable unit in your API system, making dependencies explicit and structure transparent.Authentication as a First-Class Block

In Voiden, authentication settings are not duplicated across requests or buried inside environment configurations. They exist as visible, versionable, and reusable blocks.

Why this matters:
Transparency: When you view a request, you immediately see how authentication is attached. There is no hidden behavior or silent injection of headers.
Coherence: When credentials rotate or token formats change, you update the modular block once. Every request that references it reflects the change, maintaining system-wide coherence.
Full Support for OAuth 1.0 and OAuth 2.0

Voiden allows you to integrate both signature-based legacy systems and modern delegated authorization within the same modular framework.1. OAuth 1.0 Authorization Block

Although older, OAuth 1.0 remains vital in certain enterprise environments where signature-based verification is preferred. In Voiden, this is a dedicated Authorization Block, created by typing /auth-oauth1 in your file.
Parameter
Description
consumer_key
The public identifier for your application.
consumer_secret
The private key used in generating request signatures.
access_token
The token representing the user’s authorization.
token_secret
The secret tied to the access token.
signature_method
The cryptographic algorithm for signing the request (e.g., HMAC-SHA1).

OAuth 2.0 Authorization Block

OAuth 2.0 is the modern standard used by most major identity providers (Google, GitHub, Microsoft). It’s also implemented as a modular Authorization Block, created by typing /auth-oauth2.
Parameter
Description
access_token
The token issued by the authorization server granting access to protected resources.
token_type
Specifies the token type (commonly "Bearer").
header_prefix
The prefix added before the token in the Authorization header (e.g., Authorization: Bearer ).

OAuth Flow Tips and Gotchas

For those working with complex OAuth 2.0 flows, here are essential tips to ensure a smooth integration:Callback URL & Port Whitelisting
Voiden listens for the OAuth redirect on http://localhost:9090/callback by default.
Critical: This exact URL must be registered in your OAuth provider's dashboard under "Allowed Redirect URIs" (or equivalent). Mismatches, even a trailing slash, will cause rejection.
The Discover Button
If your provider supports OpenID Connect, you can use the Discover button (available in Authorization Code and Implicit flows).
Simply enter the provider's root URL (e.g., https://accounts.google.com/), and Voiden will automatically look up and populate the required auth_url, token_url, and scope fields.
Advanced Settings Control

Collapsed by default, these settings offer fine-grained control:
add_token_to: Determines where the token is attached (most APIs expect the Header).
header_prefix: The word before the token (default: Bearer). Change this only if explicitly required by your API.
variable_prefix: Used to namespace stored token variables (default: oauth2). Crucial to prevent collisions: Assign a unique prefix (e.g., google, github) to every OAuth2 block to avoid authentication errors when using multiple providers.
client_auth: Controls how client_id and client_secret are sent during token exchange (in the Body or as a Basic Auth header).
Auto-Refresh

Enable Auto-Refresh via the checkbox for silent token renewal. For this feature to work:
Your provider must return a refresh_token during the initial token exchange.
Token configuration (like token_url and client_id) is snapshotted when you first click Get Token. If you edit these fields later, you must click Get Token again to update the snapshot.
You have a 120-second timeout to complete the browser login after clicking Get Token.
By treating OAuth as a composable, visible block, Voiden helps engineers think architecturally instead of administratively, ensuring that authentication is a robust part of the system, not a vulnerable side note.

If you believe API tooling should move beyond better forms and toward better system design, Voiden is worth exploring

Take a look at us here : https://voiden.md/

Github : https://github.com/VoidenHQ/voiden

Are you still stuck in 2010?

Dhruba Patra — Mon, 23 Feb 2026 08:12:42 +0000

Most API tooling is stuck in 2010.

They still assume every API request is a form: with a fixed layout, fixed sections, fixed mental model regardless of how your API actually works.

But is UI useful? Why do we accept all this copy-pasting, clutter, and inconsistency as “normal”?

Headers that are not needed.
Bodies that are not used.
Params scattered across requests

And somehow we call that “API documentation.”

Most API clients are optimized for filling out forms, not for designing, understanding, or maintaining APIs.

hashtag#Voiden was built around a different idea:mThat APIs are systems.

And since systems are modular, the API client should be modular as well.

In Voiden, everything is a Block: Endpoints, headers, query params, bodies, files. You assemble requests from parts, reuse them across projects, and version them like code.

No fixed forms, No fake simplicity, No pretending APIs are paperwork.

If you think API tooling should evolve past “better forms,” Voiden is worth a look.

Try out here: https://voiden.md/download
Github repo: https://github.com/VoidenHQ/voiden

Voiden Blocks: Building APIs Like LEGO

Dhruba Patra — Mon, 09 Feb 2026 11:13:41 +0000

t Voiden, we believe API development should feel like writing clean, reusable code, because it IS code.

That’s why everything in Voiden is a Block, the smallest, most flexible piece of your API world. Your endpoints, headers, query params, JSON bodies, even file attachments, all are individual Blocks you can add, remove, reorder, and reuse.

Think of it as LEGO for HTTP: snap together Blocks to build clean, modular API requests that are easy to read, maintain, and share.

But it gets better. With Reusable Blocks, you create a Block once and import it everywhere you need it, just like importing functions in your code. Update the Block once, and changes ripple through all your requests automatically.

Why this matters:

Save time & energy, no more repeating the same thing over and over
Stay consistent, headers, params, and auth always match across your projects
Keep your workspace clean & focused, add only the Blocks you need
Collaborate with confidence , modular, maintainable API workflows

Voiden brings developer best practices — modularity, reusability, and version control to API development and testing, helping you build smarter and faster.

Want to see how Blocks can transform your API workflow?

Check out Voiden, open source and ready to use.

Github : https://github.com/VoidenHQ/voiden

Voiden Blocks: Building APIs Like LEGO

Dhruba Patra — Mon, 09 Feb 2026 11:07:26 +0000

At Voiden, we believe API development should feel like writing clean, reusable code, because it IS code.

Think of it as LEGO for HTTP: snap together Blocks to build clean, modular API requests that are easy to read, maintain, and share.

Why this matters:

Save time & energy, no more repeating the same thing over and over
Stay consistent, headers, params, and auth always match across your projects
Keep your workspace clean & focused, add only the Blocks you need
Collaborate with confidence , modular, maintainable API workflows

Voiden brings developer best practices — modularity, reusability, and version control to API development and testing, helping you build smarter and faster.

Want to see how Blocks can transform your API workflow?

Check out Voiden, open source and ready to use.

Github : https://github.com/VoidenHQ/voiden

How do you handle test data in your API requests?

Dhruba Patra — Mon, 19 Jan 2026 14:02:46 +0000

We know generating realistic, dynamic test data can be a hassle - most folks rely on scripts or manual copy-pasting, which gets messy fast.
At Voiden, we built Voiden Faker to generate fresh, realistic data right inside your HTTP requests using Faker.js expressions, no extra setup needed.

We’d love to hear from you:

What’s your biggest challenge with test data?
How do you currently generate or manage it?
Would embedding Faker-like data generation inside requests help your workflow?

Try Voiden Faker here: https://voiden.md/ and share your thoughts!

API Key Authentication in Voiden

Dhruba Patra — Thu, 15 Jan 2026 07:09:25 +0000

Voiden makes it easy to work with APIs that use API Key Authentication by giving you a clean and organized way to attach API keys to every request.

API keys are a common way for APIs to identify and authorize clients. With Voiden, every request sent to your workspace APIs automatically includes the correct API key - so the API provider always knows who’s calling and whether the request is allowed.

Each client or service uses a unique API key, acting as a secure identifier attached to every request.

How it works in Voiden :

When you configure API Key Authentication, you simply:

Add api-key-auth table using /auth-api-key
Define the key name
Provide the API key value

That’s it. Voiden takes care of the rest by automatically attaching the API key to every request in your workspace.

Try Voiden here : https://voiden.md/

Using GraphQL in Voiden

Dhruba Patra — Wed, 14 Jan 2026 05:15:19 +0000

Voiden gives you two flexible ways to work with GraphQL so you can focus on writing and testing queries with confidence.
Both approaches let Voiden fully understand your types, queries, mutations, and subscriptions.

Importing a GraphQL Schema File

You can import a GraphQL schema file such as .graphql or .gql directly into Voiden.
When you do this:

Voiden reads all types, queries, mutations, and subscriptions from the schema
The schema becomes available locally and works well in offline scenarios
You get a stable, version-controlled setup that aligns nicely with Git workflows This approach is ideal when you already have the schema file and want full control over it.

Using GraphQL Introspection Alternatively, you can provide a GraphQL endpoint URL to Voiden.

In this case :

Voiden make an introspection query to the GraphQL server
The server returns all available types, queries, mutations, and subscriptions
Voiden automatically loads this information so you can start querying immediately

This option is perfect for quickly exploring a live GraphQL API or when the schema file is not available locally.

Use GraphQL in our beta version : https://voiden.md/beta

Using GraphQL in Voiden

Dhruba Patra — Tue, 13 Jan 2026 07:26:53 +0000

Importing a GraphQL Schema File

You can import a GraphQL schema file such as .graphql or .gql directly into Voiden.

When you do this:

Voiden reads all types, queries, mutations, and subscriptions from the schema
The schema becomes available locally and works well in offline scenarios
You get a stable, version-controlled setup that aligns nicely with Git workflows

This approach is ideal when you already have the schema file and want full control over it.

Using GraphQL Introspection

Alternatively, you can provide a GraphQL endpoint URL to Voiden.

In this case :

Voiden make an introspection query to the GraphQL server
The server returns all available types, queries, mutations, and subscriptions
Voiden automatically loads this information so you can start querying immediately

This option is perfect for quickly exploring a live GraphQL API or when the schema file is not available locally.

Use GraphQL in our beta version : https://voiden.md/beta

Reusable Blocks in Voiden

Dhruba Patra — Mon, 12 Jan 2026 06:05:19 +0000

What Are Reusable Blocks in Voiden?

Instead of typing the same Voiden blocks again and again (and again…), you just create a block once in a Voiden file and reuse it everywhere you want.

This saves time but also helps you keep things coinsistent: The block values can be inherited to all the documents you create and link these blocks to.

How it works :

Before importing, first create a block that can be reused across multiple Void files. Define your content and save it as a reusable block.
Type @ to show the list of linkable files or blocks
Focus on a void file and press Space bar to see the blocks of that file
Done! Your block is imported. Yes, that was simple right?

Use Voiden here : https://voiden.md/

Assertion Blocks in Voiden

Dhruba Patra — Thu, 08 Jan 2026 08:21:46 +0000

We recently added assertion blocks to Voiden.
Not because assertions are new but because they’re usually treated as an afterthought.
When testing APIs, most of us:

Send a request
Inspect the response
Mentally verify “yeah, that looks right”
Or scatter assertions across scripts, test files, or CI configs

That works… until it doesn’t.
Assertion blocks are our attempt to make expectations explicit and first-class.
Instead of burying checks in code or external tools, you define what must be true:

Status codes
Response structure
Field values
Edge cases that shouldn’t silently pass

Right next to the request itself.
This does a few important things:
Tests become readable, not just executable

Failures explain what broke, not just that something broke

API behavior becomes documented by usage, not just specs

For teams building and testing APIs, this reduces the gap between:

“I think this endpoint works”
“We know exactly what guarantees this endpoint provides.”

We are still refining how assertion blocks evolve, but the goal is simple: less guessing, more confidence, closer to how developers actually think about APIs.

If you’re testing APIs regularly, we’d love to hear how you currently handle assertions, and what’s still painful about it.

Download Voiden here : https://voiden.md/

Assertion Blocks in Voiden

Dhruba Patra — Thu, 08 Jan 2026 08:21:46 +0000

We recently added assertion blocks to Voiden.
Not because assertions are new but because they’re usually treated as an afterthought.
When testing APIs, most of us:

Send a request
Inspect the response
Mentally verify “yeah, that looks right”
Or scatter assertions across scripts, test files, or CI configs

That works… until it doesn’t.
Assertion blocks are our attempt to make expectations explicit and first-class.
Instead of burying checks in code or external tools, you define what must be true:

Status codes
Response structure
Field values
Edge cases that shouldn’t silently pass

Right next to the request itself.
This does a few important things:
Tests become readable, not just executable

Failures explain what broke, not just that something broke

API behavior becomes documented by usage, not just specs

For teams building and testing APIs, this reduces the gap between:

“I think this endpoint works”
“We know exactly what guarantees this endpoint provides.”

We are still refining how assertion blocks evolve, but the goal is simple: less guessing, more confidence, closer to how developers actually think about APIs.

If you’re testing APIs regularly, we’d love to hear how you currently handle assertions, and what’s still painful about it.

Download Voiden here : https://voiden.md/

Postman vs Voiden : Not a feature comparison but a workflow choice.

Dhruba Patra — Wed, 07 Jan 2026 07:25:46 +0000

Most API friction doesn’t come from bugs.
It comes from context switching and out-of-sync tools.
Here’s how the two approaches differ in practice:

Postman

GUI-first, platform-centric workflow
Collections live inside the tool
Git is an export / sync step
Specs, tests, and docs are maintained separately
Docs are generated artifacts and often lag behind
Cloud-first, limited offline workflows
Easy to drift out of sync during fast-moving sprints

Voiden

File-first, Git-native workflow
Plain Markdown files live directly in the repo
Git is the source of truth
Specs, tests, and docs live in the same file
What you execute is the documentation
Local-first, fully offline
No manual syncing, no stale docs, minimal context switching

As teams scale, API work stops being just testing endpoints and becomes engineering.

That’s the shift Voiden is built for.

How do you manage APIs today tool-first or Git-first?

Download Voiden here : https://voiden.md/