Skip to main content
Gruv.ai logo
API Builder

Free API Payload Builder

Choose a payment-shaped example, fill its required fields, and copy the JSON from your browser. Map it to a verified API specification before integration.

Browser onlyRequired fieldsCopy JSON
Jump to the toolBrowse all tools

Payload builder

Select an action and populate required fields.

Amount is required

Currency is required

Beneficiary ID is required

Developer tool

Payloads use generic field names for demo purposes. Map them to your API specification.

Field choices

The fields that are expensive to change later

This builder emits a generic payment payload for shaping a request, and the field names are illustrative rather than any live API schema, including Gruv. What survives the mapping exercise is the set of decisions underneath the names. How an amount is represented, what makes a request repeatable, how a time is written, and which identifier is the one both systems agree on. Those four are cheap to settle in a draft and expensive to revisit once a partner has stored a million records shaped the other way.

Amounts are the first of them. Sending 10.50 as a JSON number puts it through a binary floating point type on both ends, which is why totals drift by a cent under repeated addition, and the usual answer is an integer in the currency minor unit: 1050 for ten dollars fifty. That answer needs the exponent to travel with it, because ISO 4217 gives the yen no minor unit at all, so 1050 yen is 1050, while the Kuwaiti dinar has three decimal places and 1050 means 1.050. A payload carrying an integer with no currency exponent beside it is ambiguous by a factor of a thousand.

The reply that mapping can wait for integration is fair, and one field will not wait. An idempotency key has to be generated by the caller, at the moment the payment is created, and stored with it. Generated at send time it changes on the retry that follows a timeout, which is the exact case it exists to cover: the request that reached the server, created the payment, and lost the response on the way back. Decide that key now, along with whether times carry a UTC offset, and the rest of the mapping is renaming.

Assumptions and sources

What the generated payload represents

The builder produces a readable example request body from the fields you pick. The field names are illustrative and want mapping onto whichever API you are calling.

What it assumes

  • Generic field names are used so the shape is legible without a vendor to hand.
  • The payload is a request body, without headers, authentication or signing.
  • Values you type are placed into the structure as written. Amount and count fields are emitted as JSON numbers, and a field left blank is left out.
  • A required field left empty is flagged on screen, and the payload still builds without it.
  • Everything is generated in your browser.

What it leaves out

  • Any real API specification. Field names, types and required combinations differ per provider.
  • Authentication, idempotency keys, signing and the other headers a live call needs.
  • Validation against a schema. A payload the builder produces can still be rejected.
  • Sending the request. This page builds a body and stops.

Where the numbers come from

Field names and payload shape
Our own assumptionWritten for this page as a generic illustration. Map each field onto the specification for the API you are integrating.
Available actions
Our own assumptionA short list of common payout and payment operations chosen to cover the usual first integration.
The example response
Our own assumptionA small stored object shown beside each action, with invented identifiers and timestamps. It sketches the shape of a reply and comes from no live API.

Assumptions and sources checked 5 September 2026. Published figures move on their own schedule, so confirm anything you rely on against the authority that issues it.

Process

How it works

  1. 01

    Pick an example

    Payout, beneficiary, batch payment, or status check.

  2. 02

    Fill required fields

    Validation flags missing or malformed values.

  3. 03

    Preview the JSON

    Review the generic fields before you copy the payload.

  4. 04

    Copy + iterate

    Share with your engineering team before the integration ships.

Keep going

Related tools

Webhook Simulator

Fire the payload against your receiver to test end-to-end.

Bank Account Validator

Validate the account field before sending the payload.

Payout Failure Diagnosis

Debug the failures the API surfaces.

Go deeper

Related guides

Payment API Documentation for Reliable Integration Decisions

Executes the tool's own instruction, covering how to read and validate a payment API specification before you integrate.

Read the guide

Idempotency Keys in Payout APIs for Reliable Retry Decisions

The field a sample payload rarely teaches you to set, and the one whose absence duplicates money.

Read the guide

Testing Payment Flows in Sandbox: A Developer's Checklist

Where to send the JSON you just built, and what to assert about the response that comes back.

Read the guide

Frequently Asked Questions

Does this match the Gruv API schema?+
Payloads use generic fields for demo purposes. Map them to your final API spec.
Can I copy the JSON payload?+
Yes. Use the Copy JSON payload button to copy the generated JSON.
Is this a live API call?+
No. This tool builds payloads locally and does not send them.
Can I reset the form?+
Yes. Use the Reset button to clear all fields.
Does this include authentication?+
No. Authentication headers are not included in this tool.

Need the real production schema?

This builder is generic and does not document a Gruv API. Contact the team to ask what schema and access are available for your workflow.

Request a demoDeveloper resources

Many teams start with a narrow launch in weeks.