> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Issue a single boleto > Issues a boleto through the banking provider. The supported boleto types are TRADITIONAL and HYBRID; a request with type QR_CODE is refused with 422 PBP-0006. A HYBRID boleto can also be paid by Pix: it is issued together with a due-date Pix charge, and once its issuance is confirmed the answer carries that charge's identifier in pixTxId. The Pix code the payer scans, in qrCode, and its location, in pixLocation, are served only after the provider has registered the boleto, so that code is never paid into a boleto whose registration fails: both are absent while the boleto is PENDING, as this operation answers it, or FAILED, and GET /v1/boletos/{id} carries them once it is CREATED and on every later status. The charge is registered to the tenant's Pix receiver, configured at POST /v1/admin/pix-config: when that configuration is incomplete, when the holder of the issuing account cannot be the Pix receiver, or when the configured Pix key is a CPF or a CNPJ other than that holder's own document, a HYBRID is refused with 422 PBP-0120, whose detail names what to repair, after the final beneficiary is established and before anything is persisted or sent to the provider. A random, e-mail or phone key is not checked against the holder. On a HYBRID, a percentage charge (a fine of type PERCENTAGE, interest of type DAILY_PERCENTAGE or MONTHLY_PERCENTAGE, or a discount of type PERCENTAGE) accepts at most two decimal places, counted as written, so 2.500 carries three: an amount with more is refused with 422 PBP-0006 naming its field (fine.amount, interest.amount or discount.amount), before anything is persisted or sent to the provider. Every boleto is issued with a final beneficiary (sacador avalista): the holder of the issuing account, read from that account's registration data at issuance and returned in guarantor. This operation does not accept one: a request that sends guarantor is refused with 400 PBP-0001, naming body.guarantor as an unexpected property. The final beneficiary is established after the account checks and before anything is persisted or sent to the provider, and its refusals come in this order: 503 PBP-0118 when the registration data could not be read, or reading it is not configured; then what the registration holds, 400 PBP-0116 when the account has no registered holder, or the holder's registration is incomplete, and 422 PBP-0117 when the registered holder cannot be used as a final beneficiary; last, 422 PBP-0119 when the payer is the account holder, since a boleto cannot be issued to its own final beneficiary. None of them issues anything, and a retry under the same Idempotency-Key runs the request again. The provider account the boleto is issued on is established after the final beneficiary, on a HYBRID together with its Pix receiver, and before anything is persisted or sent to the provider. When the tenant's provider configuration cannot establish it, because the provider is not connected for the tenant, it refused the tenant's credential, or the account to issue on cannot be determined, the request is refused with 422 PBP-0017, the same on every boleto type and with or without a nosso numero; retrying it unchanged does not clear the condition. When the provider refuses that lookup, it is refused with 422 PBP-0014, and when the provider does not answer it, with 503 PBP-0015. None of them issues anything, and a retry under the same Idempotency-Key runs the request again. A nosso numero already held by an active boleto of the same provider account is refused with 422 PBP-0108 before the provider is called. When that holder can be read, the PBP-0108 detail names the boleto that holds the number, and the problem carries its id as ourNumberHolderBoletoId. When it is an earlier emission still without the provider's answer, the detail says so and does not ask for another number, because that emission can still become a live boleto; when it is a boleto the provider already answered, the detail asks for it to be consulted before another number is informed, because it may be an earlier emission of the same charge whose answer was lost. When a title the local index cannot see holds the number — for example, one issued through another deployment or another tenant sharing the provider account — the provider accepts the emission and refuses it later, and the boleto moves to FAILED, unless the title holding the number belongs to this same emission, in which case the boleto is bound to that title. The boleto stays PENDING instead when the provider's search cannot tell whose title holds the number — it lists a live title with that number that it attributes to no emission, more than one title of this same emission, or one of this emission without the provider's identifier or that disagrees with the boleto — or when the search could not be made or read whole; it also stays PENDING, transiently, while the search does not answer or is postponed to a later reconciliation pass. An issuance without a nosso numero whose outcome at the provider is not confirmed yet is answered 202 Accepted: the emission was recorded and sent, but the provider's answer was lost, could not be read or could not be recorded, and looking the emission up at the provider did not settle it. The 202 carries the recorded boleto, in status PENDING and without providerId, barcode or digitableLine. A background reconciliation completes it: it binds the boleto to its title at the provider when it finds one, and moves it to FAILED when the provider provably holds none. Read its current state with GET /v1/boletos/{id}, using the id in the body. Do not send it again under a new Idempotency-Key, since the provider may have issued it; a resend under the same Idempotency-Key answers this same 202 while the stored answer is kept. Once the read shows the boleto FAILED, it was not issued: send it again under a new Idempotency-Key, since the same Idempotency-Key answers this same 202 until the stored answer expires. Without a nosso numero, 422 PBP-0014 answers only a provider refusal that proves no title was issued, and a retry under the same Idempotency-Key runs the request again. A request under an Idempotency-Key already used for a different boleto, or naming a boleto whose emission reached the provider and failed, is refused with 422 PBP-0013; send it under a new Idempotency-Key. ## OpenAPI ````yaml /pt/openapi/v3-current/payments.yaml post /v1/boletos openapi: 3.1.0 info: description: >- API for the Lerian Payments interface via BTG. It covers boleto issuance, cancellation, and queries; bill payments (bankslip, utilities, and DARF) and queries; aggregated boleto and payment dashboards; provider connection and outbound webhook configuration; and the provider webhook receiver for settlement events. ERROR BODIES. A failed request arrives as an RFC 9457 problem document on application/problem+json. Branch on the code member. A license refusal carries an LCS code, listed in the License Manager error list. title: Payments — via BTG API version: 1.0.0 servers: - url: https://api.example.com description: >- Replace the example host with the URL provided during environment onboarding. security: [] tags: - description: >- Tenant-level setup: connecting the banking provider and configuring where status notifications are delivered. name: Admin - description: Issuing, querying and cancelling boletos, and retrieving the rendered PDF. name: Boletos - description: >- Aggregated counts, amounts and breakdowns over a period, for boletos and for payments. name: Dashboards - description: >- Paying bankslips, utility bills and DARF tax slips, and querying those payments. name: Payments - description: >- The webhook the payment provider posts settlement events to. Authenticated with a credential agreed with the provider, not with the platform identity used by the rest of this API. name: Settlement paths: /v1/boletos: post: tags: - Boletos summary: Issue a single boleto description: >- Issues a boleto through the banking provider. The supported boleto types are TRADITIONAL and HYBRID; a request with type QR_CODE is refused with 422 PBP-0006. A HYBRID boleto can also be paid by Pix: it is issued together with a due-date Pix charge, and once its issuance is confirmed the answer carries that charge's identifier in pixTxId. The Pix code the payer scans, in qrCode, and its location, in pixLocation, are served only after the provider has registered the boleto, so that code is never paid into a boleto whose registration fails: both are absent while the boleto is PENDING, as this operation answers it, or FAILED, and GET /v1/boletos/{id} carries them once it is CREATED and on every later status. The charge is registered to the tenant's Pix receiver, configured at POST /v1/admin/pix-config: when that configuration is incomplete, when the holder of the issuing account cannot be the Pix receiver, or when the configured Pix key is a CPF or a CNPJ other than that holder's own document, a HYBRID is refused with 422 PBP-0120, whose detail names what to repair, after the final beneficiary is established and before anything is persisted or sent to the provider. A random, e-mail or phone key is not checked against the holder. On a HYBRID, a percentage charge (a fine of type PERCENTAGE, interest of type DAILY_PERCENTAGE or MONTHLY_PERCENTAGE, or a discount of type PERCENTAGE) accepts at most two decimal places, counted as written, so 2.500 carries three: an amount with more is refused with 422 PBP-0006 naming its field (fine.amount, interest.amount or discount.amount), before anything is persisted or sent to the provider. Every boleto is issued with a final beneficiary (sacador avalista): the holder of the issuing account, read from that account's registration data at issuance and returned in guarantor. This operation does not accept one: a request that sends guarantor is refused with 400 PBP-0001, naming body.guarantor as an unexpected property. The final beneficiary is established after the account checks and before anything is persisted or sent to the provider, and its refusals come in this order: 503 PBP-0118 when the registration data could not be read, or reading it is not configured; then what the registration holds, 400 PBP-0116 when the account has no registered holder, or the holder's registration is incomplete, and 422 PBP-0117 when the registered holder cannot be used as a final beneficiary; last, 422 PBP-0119 when the payer is the account holder, since a boleto cannot be issued to its own final beneficiary. None of them issues anything, and a retry under the same Idempotency-Key runs the request again. The provider account the boleto is issued on is established after the final beneficiary, on a HYBRID together with its Pix receiver, and before anything is persisted or sent to the provider. When the tenant's provider configuration cannot establish it, because the provider is not connected for the tenant, it refused the tenant's credential, or the account to issue on cannot be determined, the request is refused with 422 PBP-0017, the same on every boleto type and with or without a nosso numero; retrying it unchanged does not clear the condition. When the provider refuses that lookup, it is refused with 422 PBP-0014, and when the provider does not answer it, with 503 PBP-0015. None of them issues anything, and a retry under the same Idempotency-Key runs the request again. A nosso numero already held by an active boleto of the same provider account is refused with 422 PBP-0108 before the provider is called. When that holder can be read, the PBP-0108 detail names the boleto that holds the number, and the problem carries its id as ourNumberHolderBoletoId. When it is an earlier emission still without the provider's answer, the detail says so and does not ask for another number, because that emission can still become a live boleto; when it is a boleto the provider already answered, the detail asks for it to be consulted before another number is informed, because it may be an earlier emission of the same charge whose answer was lost. When a title the local index cannot see holds the number — for example, one issued through another deployment or another tenant sharing the provider account — the provider accepts the emission and refuses it later, and the boleto moves to FAILED, unless the title holding the number belongs to this same emission, in which case the boleto is bound to that title. The boleto stays PENDING instead when the provider's search cannot tell whose title holds the number — it lists a live title with that number that it attributes to no emission, more than one title of this same emission, or one of this emission without the provider's identifier or that disagrees with the boleto — or when the search could not be made or read whole; it also stays PENDING, transiently, while the search does not answer or is postponed to a later reconciliation pass. An issuance without a nosso numero whose outcome at the provider is not confirmed yet is answered 202 Accepted: the emission was recorded and sent, but the provider's answer was lost, could not be read or could not be recorded, and looking the emission up at the provider did not settle it. The 202 carries the recorded boleto, in status PENDING and without providerId, barcode or digitableLine. A background reconciliation completes it: it binds the boleto to its title at the provider when it finds one, and moves it to FAILED when the provider provably holds none. Read its current state with GET /v1/boletos/{id}, using the id in the body. Do not send it again under a new Idempotency-Key, since the provider may have issued it; a resend under the same Idempotency-Key answers this same 202 while the stored answer is kept. Once the read shows the boleto FAILED, it was not issued: send it again under a new Idempotency-Key, since the same Idempotency-Key answers this same 202 until the stored answer expires. Without a nosso numero, 422 PBP-0014 answers only a provider refusal that proves no title was issued, and a retry under the same Idempotency-Key runs the request again. A request under an Idempotency-Key already used for a different boleto, or naming a boleto whose emission reached the provider and failed, is refused with 422 PBP-0013; send it under a new Idempotency-Key. operationId: createBoleto parameters: - description: >- Midaz organization the account and the ledger entry live under. Required: a request without it, or with a value that is not a canonical UUID, is refused with 400 PBP-0025. in: header name: X-Organization-Id schema: description: >- Midaz organization the account and the ledger entry live under. Required: a request without it, or with a value that is not a canonical UUID, is refused with 400 PBP-0025. type: string - description: >- Client-supplied idempotency key, a UUID. Required: a request without it, with a value that is not a UUID, or with the nil UUID (00000000-0000-0000-0000-000000000000) is refused with 400 PBP-0012. in: header name: Idempotency-Key required: true schema: description: >- Client-supplied idempotency key, a UUID. Required: a request without it, with a value that is not a UUID, or with the nil UUID (00000000-0000-0000-0000-000000000000) is refused with 400 PBP-0012. type: string requestBody: content: application/json: schema: $ref: '#/components/schemas/CreateBoletoRequest' required: true responses: '201': content: application/json: schema: $ref: '#/components/schemas/CreateBoletoResponse' description: >- Created. The banking provider issued the boleto: the body carries its `providerId`. Compare the 202, where the provider's answer is not confirmed yet. '202': content: application/json: schema: $ref: '#/components/schemas/CreateBoletoResponse' description: >- Accepted. The boleto was recorded and its emission was sent to the banking provider, but the provider's answer is not confirmed yet: it was lost, could not be read or could not be recorded, and looking the emission up at the provider did not settle it. The boleto is in status PENDING and carries no `providerId`, `barcode` or `digitableLine`. Do NOT send it again under a new `Idempotency-Key`: the provider may have issued it, and a second request can issue a second boleto. A background reconciliation completes it: it binds the boleto to its title at the provider when it finds one, and moves it to FAILED when the provider provably holds none. Read its current state with GET /v1/boletos/{id}, using the `id` in this body. A resend under the SAME `Idempotency-Key` is safe: it answers this same 202 while the stored answer is kept, even after the boleto is completed, so read the boleto by id for its current state. Once the read shows the boleto FAILED, it was not issued: send it again under a NEW `Idempotency-Key`, since the same `Idempotency-Key` answers this same 202 until the stored answer expires. '400': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Bad Request '401': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Authentication failed: the request carries no valid credential, or the credential does not identify a tenant. The error body is an RFC 9457 problem document (`application/problem+json`) with error code `PBP-0003`. Obtain a valid bearer token and send the request again. '403': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- The authenticated principal is not allowed to perform this request. The error body is an RFC 9457 problem document (`application/problem+json`) with error code `PBP-0004`: the principal lacks permission for this operation, and the permission has to be granted before the request can succeed. '404': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Not Found '409': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Conflict. While an earlier request under the same `Idempotency-Key` is still being processed, a request under that key is answered PBP-0007 and is not run. Send it again under the SAME key after a short wait: the key answers this code for at most five minutes after the earlier request arrived. Afterwards the same key answers with the earlier request's stored answer, with 500 PBP-0002 when that answer cannot be replayed, or, when no answer was kept, by running the request. Do not send it under a new key to get past this answer: the earlier request may still take effect. '413': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Request Entity Too Large '422': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Unprocessable Entity '500': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Internal Server Error '503': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Service Unavailable. PBP-0008 means a dependency the request needs, authentication or the tenant's storage, is temporarily unavailable. The request was not processed; wait and send the same request again with the same Idempotency-Key. security: - BearerAuth: [] components: schemas: CreateBoletoRequest: additionalProperties: false properties: amount: description: Amount as a decimal string, at most two decimal places. examples: - '100.00' maxLength: 32 type: string discount: $ref: '#/components/schemas/DiscountRequest' dueDate: description: Due date, YYYY-MM-DD. examples: - '2030-01-15' format: date type: string fine: $ref: '#/components/schemas/FineRequest' instructions: type: string interest: $ref: '#/components/schemas/InterestRequest' ledgerId: description: >- Midaz ledger the account lives in and the entry is posted to. Required: absent, blank or not a canonical UUID is refused with 400 PBP-0026. type: string midazAccountId: description: Midaz account the boleto settles into. type: string ourNumber: description: >- Bank-side identification of the boleto (nosso numero), chosen by the payee. Optional: when absent, the provider assigns the number. A HYBRID boleto takes it as a TRADITIONAL one does, from the same numbering: a number held by an active boleto of either type is in use for both. Surrounding spaces are removed. A hyphen is accepted only when followed by exactly one digit, which is discarded because the check digit is always computed by the bank: 152-3 is sent as 152, while 152- and 152-abc are refused. Any other character that is not a digit is refused. Leading zeros do not make a different number: 152 and 00000000152 are the same number for the current provider, and two active boletos of the same provider account cannot hold it at the same time, whatever their amount or due date. The accepted width is set by the connected provider (11 significant digits for the current one). Format and width refusals answer 400 PBP-0001; a provider that does not accept a number chosen by the payee refuses the field with 422 PBP-0006. A number already held by an active boleto of the same provider account is refused with 422 PBP-0108 before the provider is called. When the holder can be read, the PBP-0108 detail names the boleto that holds the number, and the problem carries its id as ourNumberHolderBoletoId; when it is an earlier emission that has no answer from the provider yet, the detail says so instead of asking for another number; otherwise it asks for that boleto to be consulted before another number is informed, because it may be an earlier emission of the same charge. After a 422 PBP-0014, or a 5xx, answered to an emission with ourNumber, the number can stay held until the periodic reconciliation resolves that emission, which it does not do before a grace period set by the deployment (30 minutes by default); meanwhile that emission can still become a live boleto, and issuing the same charge again with another number can leave two boletos for it. examples: - '00000000152' type: string payer: $ref: '#/components/schemas/PayerRequest' type: description: >- Boleto type. The supported values are TRADITIONAL and HYBRID; QR_CODE is refused with 422 PBP-0006. A HYBRID boleto can also be paid by Pix, and needs the tenant's Pix receiver configured at POST /v1/admin/pix-config: without it, or when its Pix key is a CPF or a CNPJ other than the issuing account holder's own document, the request is refused with 422 PBP-0120. examples: - TRADITIONAL type: string required: - type - payer - amount - dueDate - midazAccountId type: object CreateBoletoResponse: additionalProperties: false properties: amount: type: string barcode: type: string createdAt: type: string digitableLine: type: string discount: $ref: '#/components/schemas/DiscountResponse' dueDate: type: string fine: $ref: '#/components/schemas/FineResponse' guarantor: $ref: '#/components/schemas/GuarantorResponse' description: >- Final beneficiary (sacador avalista) of the boleto: the holder of the issuing account, read from that account's registration data at issuance. The request never chooses it, and every boleto this operation issues carries it. id: type: string instructions: type: string interest: $ref: '#/components/schemas/InterestResponse' ledgerId: description: Midaz ledger the boleto was written with. Always present. type: string organizationId: description: Midaz organization the boleto was written with. Always present. type: string ourNumber: description: >- Bank-side identification of the boleto (nosso numero), as assigned by the provider and printed on the instrument. Read from the barcode and returned in the instrument's form, with leading zeros: the width is set by the connected provider (11 digits for the current one). When the payee supplied ourNumber on issuance, this field still reports the instrument and not the value supplied: if the two differ, the value here is the one printed on the boleto, and the divergence is recorded by the service. Optional: absent for boletos issued before this field existed, and absent while the provider has not produced a valid barcode. Absence means not yet known; the periodic reconciliation fills it in once the provider produces the instrument, with no action needed from the client; it is never sent as an empty string. examples: - '00000000029' type: string ourNumberDigit: description: >- Check digit of ourNumber, computed by the bank and never accepted in a request. Optional: absent whenever the provider did not return it, in which case ourNumber is presented alone, with no trailing hyphen. It is absent in particular when the payee supplied ourNumber: the current provider returns the digit only for numbers it assigned itself. When present, the canonical presentation is {ourNumber}-{ourNumberDigit}. examples: - '3' type: string pixLocation: description: >- Location of the hybrid boleto's dynamic Pix QR code, as issued. For support and diagnostics: to pay, the payer uses qrCode. Only a HYBRID boleto carries it, and it is served together with qrCode, under the same rule: absent while the boleto is PENDING or FAILED, present once it is CREATED and on every later status; absent on every other type. examples: - pix.example.com/qr/v2/cobv/5d9a8e91c88c43db942d01a0ad92ffc3 type: string pixTxId: description: >- Identifier of the due-date Pix charge attached to a hybrid boleto. Only a HYBRID boleto carries it, and only once its issuance is confirmed; absent on every other type. examples: - 35dabf21d3b941e8a937409b8749f281 type: string providerId: description: >- Identifier the banking provider assigned to this boleto. Absent from the 202 response, while the provider's answer is not confirmed; read the boleto with GET /v1/boletos/{id} for its current state. type: string qrCode: description: >- Pix copy-and-paste code of a HYBRID boleto's Pix charge: the payload behind its QR code, which the payer scans or pastes to pay by Pix. Served only after the provider has registered the boleto, so it is never paid into a boleto whose registration fails: absent while the boleto is PENDING or FAILED, and so from the 201 and the 202 of its creation, which answer it PENDING; present on the read once the boleto is CREATED, and on every later status. Absent on a type without a Pix charge. type: string status: type: string type: type: string required: - id - organizationId - ledgerId - status - type - amount - dueDate - createdAt type: object Detail: additionalProperties: true properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -NNNN). type: string detail: description: >- A human-readable explanation specific to this occurrence of the problem. examples: - Property foo is required but is missing. type: string errors: description: Optional list of individual error details items: $ref: '#/components/schemas/ErrorDetail' type: - array - 'null' instance: description: >- A URI reference that identifies the specific occurrence of the problem. examples: - https://example.com/error-log/abc123 format: uri type: string status: description: HTTP status code examples: - 400 format: int64 type: integer title: description: >- A short, human-readable summary of the problem type. This value should not change between occurrences of the error. examples: - Bad Request type: string type: default: about:blank description: A URI reference to human-readable documentation for the error. examples: - https://example.com/errors/example format: uri type: string upstream: $ref: '#/components/schemas/Upstream' description: >- RFC 9457 extension member: the error a proxied third-party provider reported. Absent unless the emitting service explicitly surfaced one. type: object DiscountRequest: additionalProperties: false properties: amount: description: >- Discount amount as a decimal string, greater than zero. For FIXED it is in BRL with at most 2 decimal places; for PERCENTAGE it is in percent (2.5 means 2.5%) with at most 6 decimal places. On a HYBRID boleto a PERCENTAGE amount accepts at most 2 decimal places, counted as written (2.500 carries three); more is refused with 422 PBP-0006 naming discount.amount. maxLength: 32 type: string limitDate: description: >- Last date the discount applies, YYYY-MM-DD. It must be on or after the day of issuance (Brazilian calendar) and before the due date: before dueDate on a single boleto, before firstDueDate on installments. A date outside that window is refused with 422 PBP-0006. examples: - '2029-12-31' format: date type: string type: description: >- Discount type, granted when the boleto is paid on or before limitDate. One of FIXED (amount in BRL, at most 2 decimal places) or PERCENTAGE (percent of the boleto's face value, at most 6 decimal places, 2 on a HYBRID boleto). Required when a discount is sent: an absent, empty or unlisted value is refused with 422 PBP-0006. A discount also requires amount and limitDate. type: string required: - amount - limitDate type: object FineRequest: additionalProperties: false properties: amount: description: >- Fine amount as a decimal string, greater than zero. For FIXED it is in BRL with at most 2 decimal places; for PERCENTAGE it is in percent (2.5 means 2.5%) with at most 6 decimal places. On a HYBRID boleto a PERCENTAGE amount accepts at most 2 decimal places, counted as written (2.500 carries three); more is refused with 422 PBP-0006 naming fine.amount. maxLength: 32 type: string type: description: >- Fine type, charged once when the boleto is paid after its due date. One of FIXED (amount in BRL, at most 2 decimal places) or PERCENTAGE (percent of the boleto's face value, at most 6 decimal places, 2 on a HYBRID boleto). Required when a fine is sent: an absent, empty or unlisted value is refused with 422 PBP-0006. type: string required: - amount type: object InterestRequest: additionalProperties: false properties: amount: description: >- Interest amount as a decimal string, greater than zero. For DAILY_FIXED it is in BRL per calendar day with at most 2 decimal places; for DAILY_PERCENTAGE and MONTHLY_PERCENTAGE it is in percent (1 means 1%) with at most 6 decimal places. On a HYBRID boleto a DAILY_PERCENTAGE or MONTHLY_PERCENTAGE amount accepts at most 2 decimal places, counted as written (1.500 carries three); more is refused with 422 PBP-0006 naming interest.amount. maxLength: 32 type: string type: description: >- Interest type, accrued for each calendar day the boleto is paid late. One of DAILY_FIXED (amount in BRL per calendar day late, at most 2 decimal places), DAILY_PERCENTAGE (percent of the boleto's face value per calendar day late, at most 6 decimal places, 2 on a HYBRID boleto) or MONTHLY_PERCENTAGE (percent of the boleto's face value per month, accrued per calendar day over a 30-day month, at most 6 decimal places, 2 on a HYBRID boleto). Required when interest is sent: an absent, empty or unlisted value is refused with 422 PBP-0006. type: string required: - amount type: object PayerRequest: additionalProperties: false properties: address: $ref: '#/components/schemas/AddressRequest' document: description: Payer CPF or CNPJ, digits only. type: string name: description: Payer full name. type: string required: - document - name type: object DiscountResponse: additionalProperties: false properties: amount: type: string limitDate: type: string type: type: string required: - type - amount - limitDate type: object FineResponse: additionalProperties: false properties: amount: type: string type: type: string required: - type - amount type: object GuarantorResponse: additionalProperties: false properties: address: $ref: '#/components/schemas/AddressResponse' description: >- Never filled for the final beneficiary: the issuing account's registration data carries no address for it. Kept so the shape of this component does not change. document: description: >- CPF or CNPJ of the final beneficiary, the issuing account's holder, as registered. Answered whole, never masked, wherever this component appears. type: string name: description: >- Name of the final beneficiary, the issuing account's holder, as registered and in full. The printed boleto may abbreviate it; this member never does. type: string required: - name - document type: object InterestResponse: additionalProperties: false properties: amount: type: string type: type: string required: - type - amount type: object ErrorDetail: additionalProperties: false properties: location: description: >- Where the error occurred, e.g. 'body.items[3].tags' or 'path.thing-id' type: string message: description: Error message text type: string value: description: The value at the given location type: object Upstream: additionalProperties: false properties: code: description: The upstream provider's own error code, verbatim. examples: - E4001 type: string message: description: >- The upstream provider's own error message, verbatim (bounded, never its raw response body). examples: - account not found at provider type: string type: object AddressRequest: additionalProperties: false properties: city: type: string complement: type: string neighborhood: type: string number: type: string state: type: string street: type: string zipCode: type: string type: object AddressResponse: additionalProperties: false properties: city: type: string complement: type: string neighborhood: type: string number: type: string state: type: string street: type: string zipCode: type: string type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.