API testing · Beta

Test the Flow.
Not Just the Endpoint.

Know your API works the way customers use it. Pie runs your flows end to end, call by call, and hands your team what broke.

Book a demo →See what it catches
Fi
Tilt
Red Points
Dick's Sporting Goods
Lumo
Prado
Focal
Fairway
Teams testing web and mobile apps with Pie
More customers →

The difference

Five Calls. Five 200s. The Customer Still Pays $42.

Test each endpoint alone and this checkout passes. Pie tests the whole flow, carries each answer into the next call and checks that your customer gets the right result.

A sample checkout on a sample store

  1. POST /carts 200 Answer matches the specPassed Check that a cart ID came backHands cart_id to the next call Passed
  2. POST /carts/{{cart_id}}/items 200 Answer matches the specPassed Check that the trail runner is in the cart Passed
  3. POST /carts/{{cart_id}}/promo 200 Answer matches the specPassed Check that BIGSAVE50 was applied Passed
  4. GET /carts/{{cart_id}} 200 Answer matches the specPassed Check that the cart total is $0.00 Passed
  5. POST /payments 200 Answer matches the specPassed Check that the payment is $0.00Asked for $42.00 Failed
5 of 5 passedEvery endpoint answered the way its spec says. Nothing looks wrong, so this goes out. Failed at step 5The promo code never reached payment. The cart says $0.00 and payment asks for $42.00.

Where tests come from

Start From What You Have. Pie Drafts Your Tests.

Skip the rewrite. Pie turns your spec, your test cases or a UI test into tests your team can read, and a draft flow stays out of your suites until your team approves it.

  • Your API Spec

    Point Pie at an OpenAPI or Swagger file and it works out the inputs worth trying on each endpoint.

  • Your Test Cases

    Upload an Excel or CSV file, or an Xray or TestRail export. Each test case becomes a draft flow.

  • A UI Test

    Pie lifts the calls behind a test it already runs into a flow.

  • A Sentence

    Describe the flow in Pie Chat and it drafts the calls.

Pie Drafts Your Tests

Each check reads as a sentence, so anyone on your team can follow it.

Orders · a sample

Your Team Approves Each One

  • Create an orderDraft
  • Cancel an orderDraft
  • Apply a promo codeDraft

What comes back

Copy the Failing Call. See the Bug for Yourself.

Pie writes up failures in plain words and groups related ones into one issue. Your developer starts with the failing call, not a hunt for it.

A sample issue

Payment ignores the promo code

CriticalQAPOST /payments

TrackDismissSnooze until it fails againCopy as cURL

You make the call.Track it, dismiss it, or snooze it until it fails again.

Expected vs observed

Expected
The payment matches the cart total of $0.00.
Observed
The call answered 200 and asked for $42.00.

No back-and-forth.It says what should have come back and what did.

The failing call

Request

POST /payments
{ "cart_id": "c_8f2a91" }

Reply · 200

{ "amount": 42.00,
  "currency": "USD",
  "status": "requires_payment" }

Replay it.Copy the failing call as cURL, add your key and run it in your terminal.

Your environments

Read-Only Until You Say So. Every Environment, Its Own Data.

Run the same flow on each environment without mixing them up. Each one keeps its own test data, and a flow that changes data runs only where you allow it.

QA qa.api.acme.dev sku1001promoBIGSAVE50 On Failed1 issue
Staging staging.api.acme.dev sku2044promoSTAGE50 On PassedNo issues
Production api.acme.dev sku88310promoLIVE50 Off SkippedThis flow changes data
If Pie can’t reach an environment, the run says Couldn’t test, so it never reads as a pass or a bug. A trigger runs a suite on your schedule or when your CI calls it, and Run now starts one by hand.

In beta

It’s in Beta. Here’s What Works Today.

API testing is on for selected accounts, and it’s still changing. This is what you’d get today.

Works today

  • Flows. Calls run in order, and each answer can feed the next call.

  • Endpoint checks. From your spec, Pie tries missing fields, wrong types and values past their limits.

  • Imports. OpenAPI and Swagger files, plus test cases from Excel, CSV, Xray or TestRail.

  • Suites and triggers. Run a set of flows on a schedule or when your CI calls.

  • Environments. Your own test data on each one, with writes off until you allow them.

  • Issues. What failed, in plain words, with the failing call to copy.

Keep your own tools for

  • Load testing. How much traffic your API can take.

  • Penetration testing. How it holds up to a real attack.

Want It on Your Account?

Book a demo and we’ll walk you through the beta.

Book a demo →

The basics

New to API Testing? Start Here.

Get up to speed in six short answers, from what it is to which tools teams use.

API testing sends requests straight to your API and checks what comes back, with no screen in the way.

It can start as soon as the API exists, before there’s a UI to click through. A good test reads the answer as well as the status code, because a call can answer 200 and still return the wrong data.

A shopper applies a promo code that takes the cart to $0.00. The test creates a cart, adds an item, applies the code, reads the total and starts the payment.

The payment call answers 200 and asks for $42.00, so the test fails at the last step. Each call worked on its own. Together, they charge the wrong amount.

It tests a business process across a chain of calls instead of one endpoint at a time. Sign in, add to the cart, pay, confirm the order.

Each call uses what the last one returned, so the test fails where the journey breaks, even when every status code is green. That’s the idea behind end-to-end testing, one layer below the screen.

UI testing checks what a customer sees. API testing checks what the server does. It reaches logic a screen can hide, and it can run before the screen exists.

UI tests catch what API tests can’t, like a button that’s covered or a total that shows wrong. Most teams need both, and Pie runs both. See end-to-end testing with Pie for the UI side.

Functional tests ask whether a call does its job. Contract tests ask whether it still matches its spec. Negative tests ask whether it refuses bad input. Integration tests ask whether services work together.

Regression tests ask whether anything that worked stopped working. Load and security testing ask how much it can take and how it stands up to an attack.

Postman is the usual starting point, for building and saving requests by hand. REST Assured and Karate are free and exact, as long as your engineers write the tests in code and keep them current.

An agent like Pie starts from your spec or your test cases, drafts the tests and writes up what broke.

Security

Yes, Security Will Ask. Here’s What to Tell Them.

  • Writes Stay Off Until You Turn Them On.On a read-only environment, Pie only reads and skips any flow that changes data.
  • You Choose What Pie Can Reach.A run goes to an environment you added, at the address you gave it.
  • We Never Use Your Source Code to Train AI Models.Source code here means the files and code changes in your repositories.
  • Pie Has a SOC 2 Type 2 Report.Our most recent report is available on request. Data is encrypted in transit.
Security at Pie →

FAQ

Did we miss a question?
Email us directly →

What Does Beta Mean Here?

It works today and it’s on for selected accounts, so you can’t switch it on yourself yet. It’s still changing, so screens and features will move.

Book a demo and we’ll walk you through what fits your API.

We Already Use Postman. Where Does Pie Fit?

Keep Postman for building and trying requests by hand. For testing, hand Pie your test cases or your spec. Pie drafts the flows, runs them call by call and writes up what broke, with the failing call ready to copy as cURL.

Your team approves each draft and decides what gets tested. There are no test scripts to write.

Can We Bring the API Tests We Already Have?

Yes, if they’re written as test cases. Upload an Excel or CSV file, or an Xray or TestRail export. Each test becomes a draft flow, and a draft stays out of your suites until your team approves it.

Tests that would change data are converted but not sent unless you allow writes. An OpenAPI or Swagger file gives Pie your endpoints to check.

What Does Pie Check Besides the Status Code?

Whatever has to be true for the flow to work. A field is there, a value matches, a list keeps its order from last time, or a call answers within a time limit. Each check reads as a sentence, like “Check that the cart total is $0.00.”

On single endpoints, Pie also tries inputs your API should refuse and reports the ones it accepts.

Will Pie Change Data in Our Environment?

Not until you say so. Each environment has a Writes data switch. With it off, Pie only reads and skips any flow that changes data. Leave it off for production.

Can It Run From Our CI?

Yes. A trigger runs a suite on your schedule or when your CI calls it. Press Run now when you need it sooner.

What If Pie Can’t Reach Our API?

The run says so. That flow reads Couldn’t test, with the reason, so it never looks like a pass or a bug. Pie also warns you before you save an environment it can’t reach.

An internal address has to let Pie in, and we’ll set that up with you.

Does It Replace Our UI Tests?

No. UI tests catch what a customer sees, and API flows catch what the server did. Pie runs both, on web, iOS and Android, and a UI test you run in Pie can become an API flow.

Does It Cover Load or Security Testing?

Keep your dedicated tools for load testing and penetration testing. Pie checks that your API does the right thing, not how much traffic it can take or how it holds up to a real attack.

How Is It Priced?

Book a demo. We’ll walk through your API and what you want covered, and give you a quote.

Test the Whole Flow. Not Just the Endpoints.

In beta, for selected accounts. Book a demo and we’ll walk you through it.

Book a demo →See what it catches