Create a PIX charge. Returns a QR code for the customer to pay.

Create a boleto bancario charge. Returns a bank slip line for payment.

List charges for the authenticated seller with pagination and filters.

Get details of a specific charge by its uuid.

Refund a charge fully or partially. Amount is in BRL / reais (e.g. 10.50 for R$10,50). For a Pix Automatico charge the refund is asynchronous: the charge returns as refund_pending and only reaches refunded once the transfer settles.

Cancel an unpaid charge by its uuid.

Create a customer and link to the current seller.

List customers for the authenticated seller with pagination, search, and an optional 'overdue' filter that surfaces customers with at least one overdue scheduled charge.

Get details of a specific customer by numeric ID.

Update a customer's information for the current seller.

Set or clear the per-seller billing email override for a customer. The override is sticky: it takes precedence over the per-seller last-used email and the global customer.email for outbound seller-to-customer emails, and is never auto-overwritten by subsequent payments. Pass null to clear and fall back to the last-used email. Use this when the customer asks for a specific billing address (e.g. financeiro@empresa.com.br) different from the email they used at checkout.

Remove a customer from the current seller. Does not delete the customer globally.

List products for the authenticated seller with pagination and search. The UUID returned for each product is the same identifier accepted by create_pix_charge and create_boleto_charge. Each product also carries a pixAutomatic boolean — when true, Pix Automático (BACEN auto-debit recurring Pix) is offered on the public subscription checkout.

Get details of a specific product by UUID. Use this to inspect a product before creating a charge. The pixAutomatic boolean indicates whether Pix Automático (BACEN auto-debit recurring Pix) is enabled on the public subscription checkout for this product.

Get the per-product portal customization (business name, logo, primary color, cancellation policy, custom welcome / success / cancellation messages). Returns null when no per-product config exists — the product falls back to the seller-level portal config. Used by B2B2C platforms that model their professionals/coaches as Products under a single seller.

Create a product for the authenticated seller. Returns the created product, whose UUID is the same identifier accepted by create_pix_charge / create_boleto_charge. value is in decimal BRL / reais (e.g. 29.90), NOT centavos. Setting pixAutomatic: true exposes Pix Automático (BACEN auto-debit recurring Pix) on the subscription checkout. Pass idempotencyKey to make a retry across process restarts safe — the backend returns the original product instead of creating a duplicate.

Update an existing product (partial PATCH — only the fields you provide are written; everything else keeps its persisted value). value is in decimal BRL / reais (e.g. 29.90), NOT centavos. Setting pixAutomatic: true exposes Pix Automático (BACEN auto-debit recurring Pix) on the subscription checkout. At least one write field is required.

Create or merge the per-product portal customization. Both this tool and PATCH have the same merge semantics: only fields you provide are written; unspecified fields keep their persisted value. Use clear_product_portal_config (DELETE) to reset everything. Each Boolean / string field can be passed as null to inherit from the seller-level config.

Remove the per-product portal customization. The product falls back to the seller-level portal config. Returns { removed: true } when a row was deleted, { removed: false } when there was nothing to remove.

Schedule a future charge for an existing customer. Use list_customers first to find the customerId. type='one_time' is the simple case (PIX/Boleto). type='recurring' takes a recurrence config and silent-charges the saved card on every cycle past the first. Card method is recurring-only and requires productId. Pix Automático (methods: ['pix_automatic']) is BACEN auto-debit recurring Pix — the customer authorizes once and later cycles debit silently; it is recurring-only and requires productId. Optional trialDays (1..365, recurring-only) rebases cycle 1 to today + N days and emits customer.trial_started immediately.

List scheduled charges for the authenticated seller, with pagination and filters. Pass status as a single value or an array. Use search to match against the linked customer's name, email, or document.

Get a scheduled charge by ID, bundled with its event timeline and any linked Garu transactions. The response shape is { charge, events, transactions }. Unit caveat: charge.amount is decimal BRL (e.g. 297.50) but transactions[].value is centavos (BRL × 100, e.g. 29750). Convert before comparing.

Postpone a scheduled charge to a new due date. Allowed from scheduled / due_today / overdue / paused. Clears any pending dunning so the customer gets a fresh reminder on the new date.

Pause a scheduled charge. No reminders fire while paused. Allowed from scheduled / due_today / overdue. Use resume_scheduled_charge to bring it back.

Resume a paused scheduled charge. Only valid from paused.

Manually mark a scheduled charge as paid (e.g. customer paid via bank transfer outside Garu). For one-time: omit cycleNumber, allowed from due_today / overdue. For recurring: pass cycleNumber, allowed from cycle status due_today / overdue / failed; future cycles continue.

Force-bill the current cycle right now instead of waiting for its due date. Runs the same dispatch the daily billing cron would: customer email/notification + outbound webhook + timeline event. Allowed only from a billable status (scheduled / due_today); a recurring series must also have an open cycle (otherwise the gateway returns 400). IDEMPOTENT — NOT a re-charge: if this cycle's d-day was already dispatched it reports outcome 'already_sent' and does nothing, so retries are safe and never double-bill. Read the returned outcome ('dispatched' | 'already_sent' | 'not_sent' | 'failed'), the optional reason (e.g. no_email, no_saved_payment_method, card_expired, or a gateway decline code), and the pt-BR message to decide what to tell the user.

Stop future cycles for a recurring scheduled charge. The currently in-flight cycle (if any) remains active until paid, postponed, or marked-paid; only after that resolves does the series flip to recurrence_canceled. Final — use a new series to restart. Recurring-only.

Toggle Stripe-style soft cancel on a recurring series. With enabled=true, the cycle generator stops emitting new cycles after the next paid cycle (the in-flight cycle still bills + can be paid). Reversible by passing enabled=false. Mutually exclusive with recurrence.endsAfter and recurrence.endsOn.

Swap the saved card on a recurring series. The new PaymentMethod must belong to the same customerId. Future cycles silent-charge the new card; the in-flight cycle is not retroactively rebound.

Clear the saved card on a recurring series. Future cycles fall back to the email-with-link flow so the customer can re-enter card details or pay via PIX/Boleto.

Per-attempt billing log for a scheduled charge series (SPEC §4.2). One row per logical billing event: cycle 1 interactive charge, every silent-charge attempt, every retry cron retry, every manual mark-paid. Each row carries the canonical Garu failureCode for declines, the gateway raw code for forensics, and a snapshot of the card last4 / brand even after the PaymentMethod is deleted (LGPD survival). Use this to audit why a recurring series fell behind.

List webhook events for the authenticated seller. Filter by delivery status (pending, success, failed), by Garu event type (e.g. 'transaction.payment.paid'), and/or by the destination endpoint id. Use this to audit deliveries — the canonical 'did my customer's endpoint actually receive event X?' workflow. Newest first.

Fetch one webhook event by numeric id. Returns the full payload, the embedded endpoint snapshot, the most recent response status/body, and the retry schedule. Use this to drill into why a delivery is failing.

Re-deliver a webhook event by id. Resets it to 'pending' in place, clears the retry schedule, and triggers an immediate delivery attempt. Works on any status (success, failed, pending). For most cases prefer resend_webhook_event, which preserves the original event's audit trail by cloning instead of mutating — retry overwrites the historical response status/body on the source row. Kept for callers that explicitly want the legacy in-place semantics.

Re-deliver a webhook event by id, audit-trail preserving. Inserts a fresh event (new numeric id) that points back at the source via manualResendOf, then dispatches that clone — the original row is left untouched, so its prior response status/body stays on the record. Works on any status (success, failed, pending). Returns the clone event; the returned id is the new event's id, NOT the source. The customer's webhook handler will see Idempotency-Key: resend_ on the delivery, and can distinguish a resend from the original by that prefix or by the payload's manualResendOf field. Prefer this over retry_webhook_event when a customer reports a missed or unprocessed event, or during a backfill — you want the original delivery outcome to remain on the record.

Return the steps and dashboard URLs an agent needs to integrate an application with Garu: where to create an API key, where to register a webhook endpoint, and how to verify webhook signatures with the SDK. Garu does not expose programmatic endpoints for these — both have to be done in the dashboard at https://garu.com.br/configuracoes/desenvolvedores. Call this whenever the user asks how to wire up Garu in their app, set up the API key, or receive webhooks.