Introducing API Synthetic Monitoring: Monitor Multi-Step API Workflows with Rumbliq Sequences

Most API monitoring tools watch individual endpoints. They ping a URL, check that it returns 200, and call it a day. That works great for uptime — but it misses an entire class of failures that your users feel first.

What happens when your login endpoint returns 200, but the token it returns is malformed and every downstream request fails? What happens when your "create order" endpoint works fine in isolation, but the order confirmation email fails because it depends on data from a previous step? What happens when your Stripe payment flow silently breaks at step 3?

These are workflow failures — and no amount of per-endpoint monitoring will catch them.

Today we're launching Sequences: multi-step API synthetic monitoring that lets you chain requests, pass data between steps, and assert that your entire API workflow works end-to-end.

What Is a Sequence?

A Sequence is an ordered chain of HTTP requests that execute serially. Each step can extract data from the previous response and inject it into the next request. Each step can assert on status codes, response bodies, headers, response times, and schema shape.

Think of it as an automated integration test that runs on your production (or staging) API on a schedule you control.

Example: Stripe Payment Flow

Step 1: POST /auth/login
  → Extract: token = $.data.access_token

Step 2: GET /me
  → Headers: Authorization: Bearer {{login.token}}
  → Assert: status == 200, body has "email"

Step 3: POST /payments/charge
  → Headers: Authorization: Bearer {{login.token}}
  → Body: { "amount": 1000, "currency": "usd" }
  → Assert: status == 201, body has "id"
  → Extract: charge_id = $.data.id

Step 4: GET /payments/{{charge.charge_id}}
  → Assert: status == 200, body.status == "succeeded"

If any step fails — wrong status code, assertion failure, variable extraction error, or schema drift — Rumbliq fires an alert immediately and shows you exactly which step broke and why.

Variable Interpolation

Sequences use {{stepName.variableName}} syntax to pass data between steps. Variables are extracted using JSONPath from response bodies, or directly from headers and status codes.

Extraction sources:

• body — JSONPath against the JSON response body (e.g. $.data.token)
• header — A specific response header (e.g. Content-Type)
• status — The HTTP status code as a string
• response_time — The step duration in milliseconds

Example extractions:

[
  { "name": "token", "source": "body", "path": "$.data.access_token" },
  { "name": "user_id", "source": "body", "path": "$.data.user.id" },
  { "name": "content_type", "source": "header", "path": "Content-Type" }
]

In subsequent steps, reference them as {{stepName.token}}, {{stepName.user_id}}, etc. Variables work in URLs, headers, request bodies, and assertion expected values.

Assertions

Each step supports fine-grained assertions beyond basic status code checks:

Assertions can reference extracted variables in expected values — so you can assert that a value returned in step 3 matches something extracted in step 1.

Schema Drift Detection Per Step

Every step can optionally enable schema drift detection — the same engine that powers Rumbliq's regular monitors. On the first successful run, Rumbliq captures a baseline schema snapshot for that step. On subsequent runs, any structural change to the response schema fires an alert.

This means your sequences don't just verify your workflow logic — they also catch when any step's API response changes shape unexpectedly.

Teardown Steps

Production workflows often need cleanup. Mark any step as a teardown step and it runs after the main sequence completes, regardless of whether earlier steps passed or failed. Use this to:

• Delete test records created during the sequence
• Revoke tokens
• Cancel orders that were created for testing

Teardown steps appear visually separated in the sequence runner UI.

Scheduling and Limits

Sequences run on a cron schedule, just like regular monitors. Set a schedule when creating a sequence, or trigger manually at any time (up to 5 manual runs per 5-minute window).

Plan limits:

The API

Sequences are fully accessible via the Rumbliq API, making them composable with your CI/CD pipeline. Trigger a sequence run after each deploy, poll for the result, and fail the deploy if the sequence fails.

Quick example — create and run a sequence:

# Create a sequence
curl -X POST https://rumbliq.com/v1/sequences \
  -H "Authorization: Bearer dk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Auth Flow",
    "schedule": "*/5 * * * *",
    "stop_on_failure": true
  }'

# Add a login step
curl -X POST https://rumbliq.com/v1/sequences/seq_xxx/steps \
  -H "Authorization: Bearer dk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Login",
    "endpoint_url": "https://api.example.com/auth/login",
    "endpoint_method": "POST",
    "endpoint_body": "{\"email\":\"[email protected]\",\"password\":\"testpass\"}",
    "assertions": [{ "type": "status_code", "operator": "eq", "expected": "200" }],
    "extractions": [{ "name": "token", "source": "body", "path": "$.data.token" }]
  }'

# Manual run
curl -X POST https://rumbliq.com/v1/sequences/seq_xxx/run \
  -H "Authorization: Bearer dk_live_..."

Who Is This For?

API-first teams who ship frequently and need confidence that their core flows work after every deploy — not just that individual endpoints are up.

Integration developers building on top of third-party APIs (Stripe, Twilio, Plaid, SendGrid) who need to know when a multi-step vendor workflow breaks — before their users hit it.

SRE and platform teams who want transaction-level SLOs, not just endpoint-level uptime. A sequence lets you set a meaningful SLO: "our checkout flow completes in under 3 seconds, 99.9% of the time."

QA teams who want their integration test suite running continuously against production, not just in CI against a mock.

Getting Started

Sequences are available on all plans (with limits that scale with your tier). Head to the Sequences section in your Rumbliq dashboard, or start with the API:

1. Create a sequence with a name and (optionally) a schedule
2. Add steps in order — each step is a single HTTP request
3. Configure extractions to capture values from each response
4. Add assertions to verify the response meets your expectations
5. Run it manually to validate, then let the scheduler take over

If you import from Postman, you can convert an existing Postman collection into a Rumbliq sequence automatically — variable syntax is mapped, request configs are carried over, and assertions are generated from existing Postman tests where possible.

Related Posts

• synthetic API monitoring guide
• how Rumbliq works
• API monitoring complete guide

What's Next

This is the v1. What we're building next:

• Postman import — Convert a Postman collection into a sequence with one click — already live!
• Conditional step execution — Skip steps based on the result of a previous assertion
• Multi-region sequences — Run the same sequence from multiple regions with consensus
• Sequence templates — Pre-built sequences for common workflows (OAuth 2.0, Stripe, Twilio)
• Slack + PagerDuty integration — Route sequence alerts to your existing incident channels with step-level context

Sequences are live today. Sign up free or check the docs to get started.