DEV Community: FetchSandbox

Test Notion database queries without a workspace

FetchSandbox — Mon, 11 May 2026 23:44:45 +0000

Testing a Notion database query sounds simple until you try to do it in a real workspace.

You need a workspace. You need an integration token. You need to share the right database with that integration. You need seed pages with the right properties. Then you run the query and hope you did not pollute somebody's actual team dashboard with test rows.

The painful part is not POST /v1/databases/{database_id}/query.

The painful part is proving the whole shape around it:

does the database exist?
do the properties match what your app expects?
does the filter return the right rows?
does the response shape match the code path you are about to ship?
can you repeat the test without cleaning up a real Notion workspace?

The specific workflow

The narrow workflow I care about here is:

Retrieve a Notion database
Query that database for high-priority in-progress tasks
Verify the returned page shape before wiring it into an app

In FetchSandbox, the workflow is intentionally small:

GET  /v1/databases/db-a1b2c3d4-e5f6-7890-abcd-ef1234567890
POST /v1/databases/db-a1b2c3d4-e5f6-7890-abcd-ef1234567890/query

The query body filters by two properties:

{
  "filter": {
    "and": [
      {
        "property": "Status",
        "select": {
          "equals": "In Progress"
        }
      },
      {
        "property": "Priority",
        "select": {
          "equals": "High"
        }
      }
    ]
  }
}

That is the kind of test I want before touching production code.

Not "does the endpoint return 200?"

More like:

database exists -> properties match -> filter runs -> rows come back -> app can trust the shape

Why docs and mocks miss this

Docs usually show the endpoint and a sample payload.

That helps, but it does not answer the messy integration questions:

what happens when the database is missing?
what if the integration does not have access?
what if the property name is different from the sample?
what if the query returns zero pages?
what fields should my app treat as stable?

Generic mocks usually miss this too because they return static JSON. They do not behave like a workspace with pages, databases, users, blocks, comments, and state.

For a Notion integration, state matters.

If your app reads tasks from Notion, the test needs to prove more than the request syntax. It needs to prove that your app can survive the workspace shape it expects.

How I would test it

For this workflow, I would test three cases:

1. Happy path

The database exists and contains matching pages.

Expected result:

GET database -> 200
POST query -> 200
matching pages returned

This proves the app can read the expected database shape.

2. Permission denied

The database exists, but the integration should not be allowed to read it.

Expected result:

POST query -> 403
app shows setup guidance instead of crashing

This is the case most teams discover only after connecting a real workspace with incomplete permissions.

3. Empty result

The query is valid, but no pages match Status = In Progress and Priority = High.

Expected result:

POST query -> 200
results: []
app shows an empty state

This catches a surprising number of UI and sync bugs.

Where FetchSandbox fits

This is the kind of workflow a stateful API sandbox should prove.

With the Notion sandbox in FetchSandbox, you can test pages, databases, blocks, users, comments, and search without setting up a real workspace or using a real integration token.

I recorded a raw walkthrough of this Notion database workflow here:

https://youtube.com/watch?v=xJpJ5dOR_Co

The more interesting path is connecting your IDE to it.

FetchSandbox MCP lets Cursor, Claude, or another MCP-capable agent discover and run these workflows from your own development environment:

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp"]
    }
  }
}

Then you can ask the agent something like:

Use FetchSandbox MCP to explore the Notion sandbox.
Run the database query workflow and explain what response shape my app should handle.

That changes the workflow from "read docs and copy examples" to "run the integration behavior from inside the IDE."

The Notion portal is here:

https://fetchsandbox.com/docs/notion

And the Notion landing page is here:

https://fetchsandbox.com/notion

The goal is not to replace Notion.

The goal is to give developers a runnable place to understand the API lifecycle before they wire it into a real customer workspace.

For this one workflow, the question is simple:

Can my app query a Notion database and handle the response shape correctly?

That should be testable before production.

When your SaaS API has docs but no real sandbox

FetchSandbox — Fri, 08 May 2026 18:43:53 +0000

A lot of small SaaS APIs have decent docs.

Some even have an OpenAPI spec.

But no real sandbox.

That sounds fine until a developer tries to integrate the API and needs to test the part that docs cannot prove:

Does the workflow actually hold together?

Not one request.

The workflow.

The problem is not the first 200

Most API docs can show this:

POST /customers
→ 201 Created

That is useful, but it is not enough.

For a real SaaS integration, the next questions are usually:

Can I read the same customer back?
Does the subscription attach to the right customer?
Does the webhook fire?
Does my app know which user should get access?
What happens when the subscription is canceled?

This is where a docs-only API starts to feel thin.

The integration does not fail because the endpoint is unknown.

It fails because the lifecycle is not testable.

The workflow small SaaS teams should expose

If I were building a small SaaS API, the first sandbox workflow I would expose is boring:

POST /customers
  → create a customer

GET /customers/{id}
  → verify the customer exists

POST /subscriptions
  → attach a plan to that customer

GET /subscriptions/{id}
  → verify state is active or trialing

webhook: subscription.created
  → let the developer test access control

PATCH /subscriptions/{id}
  → cancel or pause

webhook: subscription.canceled
  → verify access gets removed

That workflow is not flashy.

But it answers the question every integration needs to answer:

Can my app keep its local state aligned with the API provider's state?

Why examples are not enough

Example responses are static.

They can show what a customer looks like:

{
  "id": "cus_123",
  "email": "buyer@example.com"
}

But they cannot prove the next request will remember it.

They cannot prove a subscription belongs to that customer.

They cannot prove the webhook event is shaped the same way as the API response.

They cannot prove your app removes access when the subscription changes.

That is not a docs problem. Docs are still needed.

It is a sandbox problem.

The failure mode

The most common failure is not dramatic.

It looks like this:

customer create works
subscription create works
webhook handler returns 200

Then two weeks later:

paid customer has no access
canceled customer still has access
support cannot map billing ID to app user
webhook retry created duplicate state

All the individual calls looked fine.

The workflow was never tested.

Why small SaaS APIs skip sandboxes

I understand why this happens.

A small SaaS team is usually trying to ship the core product first.

Building a second environment with fake accounts, seeded data, fake billing states, webhook retries, and lifecycle transitions is a lot of work.

So the API ships with:

docs
examples
maybe an OpenAPI file
maybe test credentials
maybe a staging workspace if you ask support

That helps.

But for developers integrating your API, the missing piece is still the same:

Can I safely run the lifecycle before touching production?

A better minimum sandbox

The minimum useful sandbox does not need to simulate your whole company.

It only needs to simulate the workflow developers are scared to test in production.

For a SaaS API, that might be:

customer → subscription → webhook → access change

For an email API:

template → send → delivered/bounced webhook

For a CRM API:

lead → contact → deal → status webhook

For a CI API:

pipeline → workflow → job → failed/rerun

The pattern is the same:

State has to move.

The next request has to see the previous request.

The webhook has to match the state change.

How I am thinking about this in FetchSandbox

This is one of the reasons I am building FetchSandbox around workflows, not just endpoints.

An OpenAPI spec can tell you:

POST /customers exists

But an integration needs to know:

POST /customers
GET /customers/{id}
POST /subscriptions
webhook subscription.created
PATCH /subscriptions/{id}
webhook subscription.canceled

That is the difference between an endpoint mock and an integration sandbox.

For small SaaS teams, I think this could be a lightweight way to give developers something close to a sandbox without building a full second production environment.

Start with one scary workflow.

Make it stateful.

Fire the webhook.

Let developers break it safely.

That is already much better than docs alone.

FetchSandbox is where I am testing this idea: turn an OpenAPI spec into a stateful sandbox with workflows developers can run before production.

Polar external_id reconciliation: the customer field that keeps checkout tied to your user

FetchSandbox — Thu, 07 May 2026 17:57:02 +0000

Checkout is not where a billing integration starts.

For a SaaS app, it usually starts one step earlier:

Can this billing customer be tied back to the right user in my app?

That tiny mapping is easy to ignore when you are just trying to get checkout working. But later, when a webhook comes in, or a subscription changes, or support asks why someone paid but still has no access, this is the field you wish you tested earlier.

In Polar, that mapping can live in customer metadata / external customer identifiers like external_id.

The bug is not dramatic

The bug usually looks boring.

Your app creates a customer:

POST /v1/customers/

You get back a Polar customer ID.

Then later your app receives something like:

customer.created
subscription.active
order.paid
benefit.granted

Now your code has to answer one question:

Which local user does this belong to?

If you only stored the provider customer ID, you can probably make it work. But if your local user ID never made it into the customer record, or your webhook handler assumes the mapping exists before it actually does, the access-control code gets messy fast.

That is where a field like external_id matters.

It is not just extra metadata. It is the bridge between billing state and product state.

The small workflow I want to test

Before touching hosted checkout, I want this workflow to pass:

POST /v1/customers/
  email: buyer@example.com
  name: Test Buyer
  external_id: user_123

GET /v1/customers/{id}
  verify id exists
  verify email survived
  verify external_id is still user_123

customer.created
  verify webhook can be reconciled back to user_123

That is it.

No payment.
No subscription access yet.
No real customer.

Just proving that the customer record your app creates can be read back and matched to the user who started the flow.

Why this catches real billing bugs

Most checkout demos focus on the happy path:

click checkout
pay
redirect back
unlock access

But production systems depend on slower, less visible steps.

Your webhook might arrive before your app finishes saving local state. Your user may open checkout in one tab and close it. A retry may deliver the same event twice. Your support tooling may need to search by internal user ID, not provider ID.

If the customer mapping is weak, all of those paths become harder.

The failure usually shows up as:

user paid but access is not granted
webhook event cannot find a local user
customer exists in Polar, but your app has no clean link to it
support sees a billing ID but cannot connect it to an account
tests pass because they only checked 201 Created

The endpoint returned success. The integration still does not know who owns the customer.

Why a static mock is not enough

A static mock can return this:

{
  "id": "cus_test_123",
  "email": "buyer@example.com",
  "external_id": "user_123"
}

But the next request is the important one.

If you call:

GET /v1/customers/cus_test_123

does the mock remember the customer you just created?

Does it preserve external_id?

Can your webhook handler use that same value to reconcile the event?

For billing integrations, state matters more than the first response. A fake 201 is not enough.

Testing it in FetchSandbox

We added Polar to FetchSandbox so this kind of pre-checkout state can be tested without a Polar token.

The useful test is not "can I call the endpoint?"

It is:

POST /v1/customers/
GET  /v1/customers/{id}
inspect customer.created

Then check whether the same customer state flows through each step.

That gives you a simple confidence check before wiring checkout, subscriptions, orders, and benefits.

It does not replace Polar's real sandbox. You still need that before launch for hosted checkout, real signatures, account configuration, and final payment behavior.

But it helps catch the boring mapping problem earlier.

And boring mapping problems are exactly the ones that become painful after someone pays.

Try the Polar sandbox — no Polar token needed.

Curious how others handle this. Do you store provider customer IDs only, or always write your internal user ID into the billing customer too?

Test Polar's customer and product API flow without an API token

FetchSandbox — Tue, 05 May 2026 14:08:40 +0000

Polar billing integrations do not start at checkout.

The first real question is usually simpler:

Can my app create the customer and product records it will depend on later?

If that part is shaky, checkout and subscription handling get harder to trust. You end up debugging billing logic when the actual bug was earlier: the customer ID did not persist, the product did not show up in the list call, or your app stored an internal user ID that never made it into the billing system.

The boring part is the important part

Polar's API has the objects you expect in a modern billing system:

customers
products
checkouts
orders
subscriptions
benefits
webhooks

The checkout flow is the part everyone thinks about. But checkout depends on earlier state.

For example, a product has to exist before you can sell it. A customer has to map back to your own user model before you can reconcile access later. Polar supports this through fields like external_id / external customer IDs, which are exactly the sort of small integration detail that becomes painful if you do not test it early.

The first workflow to prove

The first Polar workflow I want to trust is not payment. It is state.

POST /v1/customers/
  → create a customer with email, name, external_id
  → customer.created webhook fires

GET /v1/customers/{id}
  → read the same customer back
  → verify the ID and external_id survived

And for products:

POST /v1/products/
  → create a product with price data
  → product.created webhook fires

GET /v1/products/
  → verify the product appears in the catalog list

That is not a flashy workflow. It is the foundation.

If your app cannot round-trip customer and product state, you do not have a billing integration yet. You have a few API calls that happened to return 201.

Why mocks are weak here

A static mock can return:

{ "id": "cus_123", "email": "test-buyer@example.com" }

But the next request is where the truth shows up.

If you call GET /v1/customers/cus_123, does the mock know about the customer you just created? Does it preserve your external_id? Does the list endpoint include the product you created one step earlier?

Most mocks do not. Every request lives alone.

For billing APIs, that is a bad tradeoff because the whole integration is stateful. Customers, products, checkouts, orders, subscriptions, and benefits are related. Your code is not just calling endpoints. It is moving through a lifecycle.

Testing Polar in FetchSandbox

We onboarded Polar into FetchSandbox today.

The current sandbox includes:

Polar OpenAPI spec support
seeded customers, products, and subscriptions
stateful customer creation and read-back
stateful product creation and list verification
webhook events like customer.created and product.created
subscription states like active, past_due, canceled, revoked, trialing

You can run the customer workflow without a Polar token, without creating a Polar organization, and without touching real payment state:

POST /v1/customers/
GET  /v1/customers/{id}

Or test product creation:

POST /v1/products/
GET  /v1/products/

The useful part is not that the first call returns a successful response. The useful part is that the second call can prove the first one changed state.

What this catches early

This kind of preflight catches boring bugs before they become billing bugs:

your app loses the billing customer ID
external_id does not map cleanly back to your user
product creation succeeds but your catalog query does not find it
your webhook handler assumes a customer exists before the create event is processed
your tests only check status codes, not persisted state

None of these are dramatic. They are just the kind of bugs that waste an afternoon once checkout and subscriptions are already wired.

Where the real Polar sandbox still matters

This is not a replacement for testing against Polar's own sandbox before launch.

You still want the real environment for final payment behavior, account-specific configuration, hosted checkout, signatures, and anything that depends on Polar's production logic.

The point is earlier than that.

Before you do final validation, you should be able to prove your app understands the basic lifecycle:

Create billing object
Store returned ID
Read it back
React to the webhook
Keep your local state aligned

That is the layer FetchSandbox is good at.

Try the Polar sandbox — no Polar token needed.

Curious how other teams test billing integrations before real payment flows. Do you start with the provider sandbox immediately, or do you preflight the API state first?

How to test Twilio message delivery failures locally

FetchSandbox — Fri, 01 May 2026 13:48:32 +0000

Twilio usually gives you the first 201 before it gives you the real problem.

That is what makes SMS bugs annoying.

You call the Messages API. Twilio accepts it. You get a SID back. Your app marks the notification as "sent" and everybody moves on.

Then the message never arrives.

Sometimes the destination number is bad. Sometimes the carrier rejects it. Sometimes the message moves through queued or sent and then lands in undelivered. The first API call still looked fine, so the debugging starts late.

That is the part I think a lot of Twilio examples skip. The useful test is not just "can I POST /Messages.json?" The useful test is "what does my app do after Twilio accepts the message but delivery goes sideways?"

The narrow workflow that matters

For local testing, the flow I care about is very small:

send the message
fetch the message again by SID
check what status your app sees next
confirm your retry, alerting, or customer-facing state does not pretend the message was delivered

In Twilio terms, that usually starts here:

curl -X POST \
  "https://api.twilio.com/2010-04-01/Accounts/AC.../Messages.json" \
  --data-urlencode "To=+14155551234" \
  --data-urlencode "From=+15017122661" \
  --data-urlencode "Body=Your order has shipped" \
  -u "$TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN"

and then immediately becomes:

curl \
  "https://api.twilio.com/2010-04-01/Accounts/AC.../Messages/<message_sid>.json" \
  -u "$TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN"

That second read is where the truth starts showing up.

Where teams usually fool themselves

The easy mistake is treating 201 Created as success for the whole job.

It is only success for the first step: Twilio accepted your request and created a message resource. It is not proof that the carrier accepted it, not proof that the handset got it, and definitely not proof that your follow-up logic handled a bad delivery outcome correctly.

That gap creates a bunch of quiet bugs:

your UI says "message sent" too early
your retry job never runs because the app thinks the work is already done
your webhook or polling code handles delivered but not undelivered
support ends up debugging customer complaints that started as an async status transition, not a failed API request

What I would test before production

If I only had time for one narrow Twilio test, I would test the branch where the message gets accepted first and fails later.

That means checking:

your app stores the SID from the first response
you can fetch the message again and read the later status instead of assuming the first response told the whole story
your callback or polling path updates the final state correctly
the rest of your system reacts differently to delivered vs undelivered

This is the same reason SMS flows feel harder than they look in Postman. Postman proves the request shape. It does not prove the delivery story.

Why this is a better local test than another happy path

A happy path SMS demo is easy to trust too early.

You send one message, get one SID, see one success response, and tell yourself the integration is basically done.

But the production pain usually sits in the branch after that:

carrier rejection
invalid destination
quiet delivery failure
app state that never gets corrected after the async update

That is why I like narrow workflow tests more than broad "Twilio integration" tests. A small delivery-failure workflow tells you more than a generic sandbox smoke test ever will.

If you want to make this easier locally

I wrote a runnable Twilio docs portal on FetchSandbox because I kept wanting the same thing: send the message, fetch it again, and inspect the later state without jumping between too many tools.

The useful part is not just mocking the first response. It is being able to test the full "accepted first, failed later" branch before production traffic teaches it to you.

Curious how other people handle this one. Do you mostly poll message state, rely on callbacks, or just treat the first 201 as "good enough" until support says otherwise?

Why Paddle's subscription.activated arrives before subscription.created

FetchSandbox — Thu, 30 Apr 2026 23:57:15 +0000

You'd think events fire in the order things happen. They don't.

I was building a Paddle integration last week. Subscription billing, nothing fancy. Customer clicks buy, Paddle handles checkout, my app gets webhooks and updates the database.

The flow should be simple:

Customer completes checkout
subscription.created fires
subscription.activated fires
My app inserts a row on .created, updates status on .activated

That's what I built. It worked great in my head.

What actually happened

In production, subscription.activated arrived before subscription.created about 30% of the time.

My handler did a database insert on subscription.created:

case 'subscription.created':
  await db.insert(subscriptions).values({
    paddleId: event.data.id,
    status: 'created',
    customerId: event.data.customer_id,
  });
  break;

And an update on subscription.activated:

case 'subscription.activated':
  await db.update(subscriptions)
    .set({ status: 'active' })
    .where(eq(subscriptions.paddleId, event.data.id));
  break;

When .activated arrived first, the update found zero rows. No error, no exception. The WHERE clause just matched nothing. The update silently did nothing.

Then .created arrived and inserted the row with status created. But the .activated event was already gone. So the subscription was stuck in created status forever.

Customers had paid. Paddle showed them as active. My app showed them as pending. Support tickets started coming in.

Why this happens

Paddle does not guarantee webhook delivery order. Their docs mention it briefly but it's easy to miss when you're focused on the API endpoints.

The events are fired from different internal services. subscription.created comes from the subscription service. subscription.activated comes from the billing service after payment confirmation. They are async. They race.

This is not unique to Paddle either. Stripe has the same problem with payment_intent.created vs charge.succeeded. Most payment providers have some version of this.

The fix

The handler needs to be idempotent and order-independent. Every event should be able to create or update:

case 'subscription.created':
case 'subscription.activated':
  const status = event.event_type === 'subscription.activated' 
    ? 'active' : 'created';

  await db.insert(subscriptions)
    .values({
      paddleId: event.data.id,
      status,
      customerId: event.data.customer_id,
    })
    .onConflictDoUpdate({
      target: subscriptions.paddleId,
      set: { 
        status: sql`CASE WHEN ${status} = 'active' THEN 'active' ELSE ${subscriptions.status} END`
      },
    });
  break;

The key parts:

Both events can create the row if it doesn't exist
On conflict, active always wins over created regardless of arrival order
No silent failures, no missing updates

Testing this is the real problem

The ordering bug is easy to fix once you know about it. The hard part is reproducing it during development.

You can't control the order Paddle sends webhooks. You can't make .activated arrive first on demand. In testing you might run through the flow 20 times and the events always arrive in order. Then in production with real network latency and load, they don't.

I ended up testing this by sending the webhook events manually in the wrong order against a local sandbox. activated first, then created. Immediately saw the bug. Fixed it in 10 minutes.

The debugging in production took 4 hours.

If you're integrating Paddle or any payment provider with webhooks, test with events arriving in every possible order. Not just the happy path order from the docs.

Test Paddle webhook ordering in a sandbox →

The takeaway

Webhook events are not a queue. They are concurrent messages from different services that happen to be about the same thing. Your handler has to treat every event as potentially the first one it sees for that resource.

If your handler has an insert for one event type and an update for another, you have this bug. You just haven't hit it in production yet.

How to test Stripe Connect transfers without a connected account

FetchSandbox — Thu, 30 Apr 2026 13:20:11 +0000

The transfer API call is easy. The testing setup is not.

Stripe Connect lets platforms move money to connected accounts.

The API is four calls:

Create a transfer to a connected account
Verify the transfer.created webhook fires
Create a payout from the connected account
Verify the payout.created webhook fires

On paper, that is maybe ten minutes of reading.

In practice, getting to the point where you can actually test this flow takes much longer than the code itself.

The setup tax

Before you can make a single test transfer, you need:

A platform account with Connect enabled
A connected account that has completed onboarding
That connected account needs a verified external account (bank details) for payouts
Your platform needs the right capabilities configured
Enough test balance in the right currency

That is a lot of infrastructure for what is ultimately four API calls.

Most developers skip the full setup. They test the transfer call in isolation, hardcode a connected account ID, and hope the payout works the same way in production.

That is not really testing the integration. That is testing one endpoint with a hardcoded parameter.

The part people skip

The webhook verification is the part that matters most and gets tested least.

In production, transfer.created is how your system knows funds actually moved. If your webhook handler is not processing that event correctly, your app might show a successful transfer to the user while the money is still sitting in your platform account.

Same for payout.created. Your connected account's dashboard should reflect the payout, but if the webhook never fires or your handler drops it, the seller thinks they got paid and you have a support ticket in 48 hours.

Testing this against real Stripe means:

Setting up a webhook endpoint reachable from the internet
Waiting for Stripe to deliver the event
Parsing the event and verifying the payload contains the right transfer ID
Making sure your handler is idempotent in case Stripe retries

Most teams punt on this and test it manually in staging. Once. And then never again.

What the flow actually looks like

POST /v1/transfers
  → 200: { id: "tr_1abc...", amount: 5000, currency: "usd" }
  → webhook: transfer.created fires with transfer ID

GET /v1/transfers/tr_1abc...
  → 200: { status: "paid" }

POST /v1/payouts
  → 200: { id: "po_2def...", amount: 5000 }
  → webhook: payout.created fires with payout ID

GET /v1/payouts/po_2def...
  → 200: { status: "paid" }

Four calls. Two webhooks. Each step depends on IDs and state from the previous one.

The transfer ID from step 1 is what your system uses to track the money. The payout in step 3 only makes sense if the transfer actually landed. The webhooks in between are what your production system will rely on to update its own state.

If you only test each endpoint individually, you are testing four unrelated API calls. You are not testing a transfer-to-payout flow.

The gap between endpoint and flow

This is the same pattern that shows up across almost every multi-step API integration.

Each endpoint works fine on its own. The docs explain each one clearly. But the docs do not usually explain:

What order to call them in
Which IDs carry from one step to the next
Which webhooks fire between steps
What happens if you skip a step or call them out of order

That gap is where the debugging time lives.

Not in the API call itself. In the space between calls.

Running the whole thing without the setup

I wanted a way to test this flow without setting up a connected account, without configuring capabilities, and without waiting for webhook delivery.

So I built a sandbox where you paste the curl and the state persists between calls. The transfer creates a real resource in the sandbox. The webhook fires automatically. The payout references the actual transfer. The IDs chain through every step.

No Stripe API key. No connected account. No webhook endpoint to host.

You verify the workflow, not just individual endpoints.

Try the Stripe Connect workflow

The honest version

I do not think this replaces Stripe test mode. If you are testing real card capture, real checkout flows, or anything that touches Stripe's actual infrastructure, you should use test mode.

But if you are trying to answer a simpler question — "does my transfer-to-payout flow work end to end, including the webhooks?" — you should not need 30 minutes of setup to find out.

That is the part I am trying to fix with FetchSandbox.

Curious how other teams handle Connect testing. Do you maintain a permanent test connected account, set up a fresh one for each project, or just skip the webhook verification and hope for the best?

Test Paddle webhooks without account verification

FetchSandbox — Wed, 29 Apr 2026 14:07:21 +0000

You can't test a Paddle subscription cancel webhook until Paddle has verified your business. That takes days.

Paddle's billing API handles subscriptions, payments, and the entire checkout flow. The API is clean and the docs are solid.

The problem is the sandbox.

Verification before testing

To get a Paddle sandbox account, you need to:

Sign up and create a separate sandbox login
Wait for Paddle to verify your business (this can take days)
Set up products and prices in the sandbox dashboard
Configure webhook URLs
Use test card numbers for checkout

All of this before you can test whether your code correctly handles a subscription.canceled webhook.

If you're building a billing integration and you want to test the full lifecycle — create subscription, pause, resume, cancel — you're waiting on Paddle's verification process before you can write a single test.

The lifecycle is the hard part

The individual API calls are straightforward. The hard part is the lifecycle:

Create a subscription → status is active
Pause it → status changes to paused, webhook fires
Resume it → status changes back to active, webhook fires
Cancel it → status changes to canceled, webhook fires

Each transition produces a webhook event. If your handler doesn't process them in the right order, or misses one, your app's subscription state drifts from Paddle's.

You can't test this sequence without a working sandbox. And you can't get a working sandbox without verification.

Testing the lifecycle without waiting

FetchSandbox has a Paddle sandbox with the full subscription lifecycle. No verification, no account setup, no test cards.

The workflow:

POST /subscriptions — create a subscription
POST /subscriptions/{id}/pause — pause it, webhook fires
POST /subscriptions/{id}/resume — resume it, webhook fires
POST /subscriptions/{id}/cancel — cancel it, webhook fires

Each step is stateful. The subscription ID chains between requests. The status transitions follow Paddle's actual state machine. Webhooks fire at each step.

Why this matters for billing

Billing bugs are silent. A missed subscription.canceled webhook doesn't throw an error — it just means a cancelled customer keeps access. You find out weeks later when you're reconciling revenue and the numbers don't match.

Testing the full lifecycle — not just the happy path, but pause/resume/cancel — is how you catch these before they cost you money.

Try the Paddle sandbox — no signup, no verification, runs in your browser.

Test Datadog API endpoints without an API key

FetchSandbox — Mon, 27 Apr 2026 13:56:55 +0000

You need an API key and an application key before you can make a single call. That's two keys, two permissions scopes, and a paid account.

Datadog's API is well-documented. The endpoints are clean, the response shapes are consistent, and the SDKs cover every major language.

The problem is testing.

Two keys before you start

To call any Datadog endpoint, you need:

A DD-API-KEY — tied to your organization
A DD-APPLICATION-KEY — tied to a specific user with specific permissions

You can't get either without a Datadog account. Free trials exist, but they require a credit card and install an agent on your infrastructure.

If you're building an integration — say, a dashboard that pulls monitors and incidents, or a CI pipeline that posts deployment events — you have to set all of that up before you can test whether your code handles the response correctly.

The shape matters more than the data

Most of the time, what you actually need to validate isn't "does Datadog return my real monitors." It's:

Does my code handle the pagination format?
What does the response look like when a monitor has no tags?
What happens when I create an incident and immediately query it — does the state transition work?

These are integration logic questions, not data questions. You don't need your production monitors to answer them.

Testing the flow without an account

FetchSandbox has a Datadog v2 sandbox with every endpoint callable immediately. No keys, no agent install, no account.

The sandbox is stateful — create a monitor, then list monitors, and the one you just created shows up. Create an incident, transition it to resolved, and the state change persists.

A workflow that tests the incident lifecycle:

POST /api/v2/incidents — create an incident
GET /api/v2/incidents/{id} — verify it exists with status active
PATCH /api/v2/incidents/{id} — transition to resolved
GET /api/v2/incidents/{id} — confirm the state changed

Each step chains IDs from the previous one. The sandbox handles this automatically.

Where this matters

If you're building Datadog integrations and your test suite currently requires a live Datadog org, every test run is a network call to production. When Datadog has an outage or rate-limits your key, your CI breaks for reasons that have nothing to do with your code.

Running the same tests against a sandbox that behaves like the real API — but doesn't require auth or network — isolates the thing you're actually testing: your integration logic.

Try the Datadog sandbox — no signup, runs in your browser.

Testing Resend's template email flow end to end

FetchSandbox — Sat, 25 Apr 2026 14:06:02 +0000

Three API calls. One template ID that has to carry through all of them.

Resend's API for sending a templated email is three steps:

Create a template
Publish the template
Send an email using that template

Each step depends on the one before it.

The template ID from step 1 has to be passed into step 2. The published status from step 2 has to be confirmed before step 3 will actually send. And if you want to verify your integration end to end, you need the template.created webhook to fire after step 1.

That is a simple flow. But most developers do not actually test it as a flow.

How most people test this

The typical approach:

Create a template in the Resend dashboard manually
Copy the template ID into your code
Call the send endpoint with that hardcoded ID
Check your inbox

That tests one thing: can your code call POST /emails with a valid template ID?

It does not test:

Whether your code correctly creates templates via the API
Whether the publish step returns the right status
Whether the template ID chains correctly from creation to sending
Whether the template.created webhook fires and your handler processes it
Whether the whole flow works when run programmatically, not manually

Hardcoding a template ID is not integration testing. It is calling one endpoint with a known parameter.

What the real flow looks like

POST /templates
  → 200: { id: "tpl_abc123", object: "template" }
  → webhook: template.created fires

POST /templates/tpl_abc123/publish
  → 200: { id: "tpl_abc123", status: "published" }
  → webhook: template.published fires

POST /emails
  → 200: { id: "email_xyz789" }
  body: { template_id: "tpl_abc123", to: "user@example.com" }

Three calls. Two webhooks. The template ID threads through every step.

The question you should be able to answer before shipping is not "does POST /emails work?" It is "does my entire template-to-send pipeline work when the template is created, published, and referenced programmatically?"

The webhook part

Most email integrations skip webhook verification entirely.

That is understandable. For a simple "send one email" integration, you might not need webhooks at all.

But once you are building a system that creates templates dynamically — onboarding flows, transactional sequences, marketing automation — you probably want to know when a template was created and when it was published.

template.created tells your system the template exists. template.published tells your system it is safe to reference in send calls.

If your code sends an email with a template that has not finished publishing, you get a confusing error that looks like a bad template ID. The actual issue is a timing problem in your flow.

Testing the webhooks is how you catch this before production.

The testing setup problem

To test this flow against real Resend, you need:

A Resend API key
A verified sender domain
A real email address to receive the test send
A webhook endpoint reachable from the internet

That is reasonable for a production integration test.

It is less reasonable for the Tuesday afternoon when you just want to know if your template creation flow works before you wire it into your app.

Running it without any of that

I built a sandbox where you can run this exact flow without a Resend API key, without a verified domain, and without hosting a webhook endpoint.

You call POST /templates. The sandbox creates a template and returns a real ID. You call POST /templates/{id}/publish. The status updates. You call POST /emails with that template ID. The send succeeds. The webhooks fire automatically between steps.

The state persists. The IDs chain. The whole flow runs in about 30 seconds.

Try the Resend template workflow

Why this matters for email integrations specifically

Email is one of those integrations where "it worked in testing" and "it works in production" can be very different things.

Templates get created but not published. Send calls reference stale template IDs. Webhook handlers assume the template exists before the creation event arrives.

These are not exotic edge cases. They are the normal bugs that happen when you test endpoints in isolation instead of testing the flow.

The fix is not complicated. Run the whole chain once, in order, with state that carries between steps. If the template ID from step 1 appears correctly in step 3, your integration probably works. If it does not, you want to find out now, not when your onboarding emails start failing.

That is what FetchSandbox does. Turns any OpenAPI spec into a stateful sandbox with workflows.

Curious how other people handle email integration testing. Do you test against real Resend with test keys, use a mock, or mostly just trust the dashboard and check your inbox?

How to test GitHub merge conflicts locally

FetchSandbox — Wed, 22 Apr 2026 04:47:25 +0000

The happy path for a pull request is boring. The merge conflict is where the integration usually gets real.

Most GitHub API demos stop too early.

They show how to open the pull request, fetch it, maybe list reviews, and then call it done.

That is useful for proving your auth works. It is not enough for proving your PR automation works.

The harder branch is the one where the pull request exists, the metadata looks fine, and then the merge step hits a conflict. That is the path that decides whether your bot, internal tool, or release workflow can recover sanely.

The small workflow that actually matters

For this kind of test, I care about a very small flow:

open the pull request
fetch the PR again to inspect its status
try the merge step
see what your system does when the PR is not cleanly mergeable

That starts with something like:

curl -X POST \
  "https://api.github.com/repos/acme-corp/api-gateway/pulls" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -d '{
    "title": "fix: handle nil pointer in rate limiter",
    "body": "Fixes #142. Adds nil check before accessing connection pool.",
    "head": "fix/rate-limiter-nil",
    "base": "main"
  }'

and then quickly becomes:

curl \
  "https://api.github.com/repos/acme-corp/api-gateway/pulls/<number>" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json"

The useful part is not just that the PR exists. It is what your code does when the branch cannot merge cleanly after that.

Where teams usually get fooled

The trap is treating "pull request created" as proof that the automation is basically done.

But a lot of GitHub workflows only become interesting after creation:

the branch is stale
another change landed on main
the PR looks valid but is not mergeable
your bot tries to continue anyway
your UI says "ready" even though a human now has to intervene

That is the same pattern that shows up in a lot of async integrations: step 1 succeeds, so the app assumes the whole job is healthy.

What I would test before production

If I only had time for one narrow GitHub API test, I would test the merge-conflict branch.

I would check:

can my app detect that the PR exists but is not safely mergeable?
do I expose the right state to the user, instead of pretending it is still a normal merge path?
do retries keep hammering the same PR, or do we stop and surface the conflict clearly?
if there is a webhook or follow-up read in the flow, does the final state stay honest?

That last part matters more than the first API call.

A lot of automation bugs are not "could not create PR."

They are more like:

"we created it, then misread the later state"
"we retried the wrong step"
"we told the user merge was blocked too late"

Why this is a better test than another PR happy path

A happy-path pull request test mostly proves you can talk to GitHub.

A merge-conflict test tells you whether your integration can survive a normal repo state that changes under it.

That is a much better signal for:

release tooling
AI coding agents opening PRs
internal automation that tries to auto-merge fixes
any workflow that assumes the branch state will stay clean between creation and merge

It is also more realistic. Real repositories drift constantly. If your testing never touches the conflict branch, your merge logic is probably getting too much credit.

The part I think is underrated

The useful question is not just:

"can I create a PR through the GitHub API?"

It is:

"when the PR stops being mergeable, do I still know what happened and what to do next?"

That is the gap between endpoint testing and workflow testing.

The endpoint docs explain the request shape. The real integration job is deciding what your system should do after the branch state changes.

If you want to make this easier locally

I like testing this as a narrow workflow instead of a broad "GitHub API integration" check.

That is also why I keep a runnable GitHub docs portal on FetchSandbox around. The useful part is being able to open the PR, fetch it again, and inspect the later branch in one place instead of stopping at creation.

For me, the merge-conflict path is one of those cases where a small failure-mode test teaches more than a longer happy-path demo.

Curious how other people handle this. If your GitHub automation opens a PR and later hits a conflict, do you surface that as a first-class state, or does it still turn into log-diving and confused retries?

How to test Stripe webhook signatures locally without breaking verification

FetchSandbox — Fri, 17 Apr 2026 16:24:17 +0000

The request usually succeeds first. The signature check is where the time disappears.

Most Stripe integrations do not fail on the first API call.

You create the customer. You create the PaymentIntent. You confirm it. Everything looks fine. Then the webhook arrives and your handler says invalid signature.

That is usually the moment the debugging session starts.

The annoying part is that the failure often has nothing to do with Stripe itself. It is usually your local setup. The payload got parsed too early. The raw body changed. The signature was generated against bytes your app never saw.

One common example in Node/Express is using express.json() on the webhook route. That middleware parses and re-serializes the body, which means the bytes you verify are no longer the bytes Stripe signed.

Instead of this:

app.post("/webhooks/stripe", express.json(), (req, res) => {
  const sig = req.headers["stripe-signature"];
  const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  res.sendStatus(200);
});

you usually need the raw body on that route:

app.post("/webhooks/stripe", express.raw({ type: "application/json" }), (req, res) => {
  const sig = req.headers["stripe-signature"];
  const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  res.sendStatus(200);
});

The hard part is not just fixing the route once. It is trusting that the whole flow still works after the fix:

the webhook arrives
the signature verifies
your handler updates state correctly
retries do not double-process the event

That is why webhook testing feels weirdly slippery. The API call and the webhook handler are two different systems, and most local setups only make one of them easy to observe.

What to test instead of the webhook in isolation

What has helped me most is testing the full flow instead of testing the webhook in isolation:

trigger the upstream action
inspect the exact webhook payload and headers
verify the handler against the raw body
confirm the final state change after the webhook is processed

That last step matters more than most examples admit. A verified signature is good. A verified signature plus the correct final state is what actually tells you the integration works.

Why this bug sticks around

Webhook bugs are slippery because the API call and the webhook handler live on two separate timelines.

The API request can succeed immediately. The event can arrive later. Your logs for one may be clean while the other is quietly failing. That is why developers end up jumping between local tunnels, dashboard events, request logs, and app state, trying to piece together what actually happened.

The hard part is rarely "can I trigger a Stripe event?" The hard part is "can I trust the whole PaymentIntent plus webhook path enough to ship it?"

A more useful local testing setup

If you want a shortcut, use a webhook sandbox or a test environment that lets you inspect the full Stripe flow end-to-end instead of only replaying one event at a time.

The useful part is not the mock payload. It is being able to see the request, the event, and the resulting state in one place.

For Stripe-specific workflow context, this is also why a runnable Stripe portal is more useful than example requests alone.

Curious what other people use here. Do you mostly replay events, tunnel to localhost, or test the full PaymentIntent plus webhook path every time?