---
title: "Update a Billing Request Template"
method: PUT
path: "/billing_request_templates/{billing_request_template_id}"
tags: ["Billing Request Template"]
---

# Update a Billing Request Template

`PUT /billing_request_templates/{billing_request_template_id}`

## Request

- Base URL: `https://api.gocardless.com`
- URL: `https://api.gocardless.com/billing_request_templates/{billing_request_template_id}`
- Auth: HTTP bearer

Updates a Billing Request Template, which will affect all future Billing Requests created by this template.

## Path parameters

- `billing_request_template_id` string, required

## Headers

- `GoCardless-Version` string, required

## Request body

- object
  - `billing_request_templates` object
    - `name` string: Name for the template. Provides a friendly human name for the template, as it is shown in the dashboard. Must not exceed 255 characters.
    - `mandate_request_currency` string, nullable: [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217#Active_codes) currency code.
    - `mandate_request_scheme` string, nullable: A bank payment scheme. Currently "ach", "autogiro", "bacs", "becs", "becs_nz", "betalingsservice", "faster_payments", "pad", "pay_to" and "sepa_core" are supported. Optional for mandate only requests - if left blank, the payer will be able to select the currency/scheme to pay with from a list of your available schemes.
    - `mandate_request_verify` 'minimum' | 'recommended' | 'when_available' | 'always', nullable: Verification preference for the mandate. One of: - `minimum`: only verify if absolutely required, such as when part of scheme rules - `recommended`: in addition to `minimum`, use the GoCardless payment intelligence solution to decide if a payer should be verified - `when_available`: if verification mechanisms are available, use them - `always`: as `when_available`, but fail to create the Billing Request if a mechanism isn't available By default, all Billing Requests use the `recommended` verification preference. It uses GoCardless payment intelligence solution to determine if a payer is fraudulent or not. The verification mechanism is based on the response and the payer may be asked to verify themselves. If the feature is not available, `recommended` behaves like `minimum`. If you never wish to take advantage of our reduced risk products and Verified Mandates as they are released in new schemes, please use the `minimum` verification preference. See [Billing Requests: Creating Verified Mandates](https://docs.gocardless.com/docs/collect-payments/setting-up-mandates/verified-mandates) for more information.
    - `mandate_request_metadata` BillingRequestTemplateMandateRequestMetadata, nullable: Key-value store of custom data that will be applied to the mandate created when this request is fulfilled. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.
    - `payment_request_description` string, nullable: A human-readable description of the payment and/or mandate. This will be displayed to the payer when authorising the billing request.
    - `mandate_request_description` string, nullable: A human-readable description of the payment and/or mandate. This will be displayed to the payer when authorising the billing request.
    - `mandate_request_constraints` BillingRequestTemplateMandateRequestConstraints, nullable: Constraints that will apply to the mandate_request. (Optional) Specifically required for PayTo and VRP.
      - `start_date` string, nullable: The date from which payments can be taken. This is an optional field and if it is not supplied the start date will be set to the day authorisation happens.
      - `end_date` string, nullable: The latest date at which payments can be taken, must occur after start_date if present This is an optional field and if it is not supplied the agreement will be considered open and will not have an end date. Keep in mind the end date must take into account how long it will take the user to set up this agreement via the Billing Request.
      - `max_amount_per_payment` integer: The maximum amount that can be charged for a single payment in the lowest denomination for the currency (e.g. pence in GBP, cents in EUR). _Note:_ Required for PayTo and VRP.
      - `payment_method` string: A constraint where you can specify info (free text string) about how payments are calculated. For use when payments vary and cannot be expressed as a fixed amount and frequency. _Note:_ This is only supported for ACH and PAD schemes.
      - `periodic_limits` object[]: Caps on the total amount and/or number of payments that can be collected within a repeating period (e.g. no more than a set amount per month), as opposed to `max_amount_per_payment` which caps a single payment. _Note:_ Required for VRP, where exactly one periodic limit must be provided. Optional for PayTo.
        - `period` 'day' | 'week' | 'month' | 'year' | 'flexible': The repeating period for this mandate. Required whenever a periodic limit is provided (for both VRP and PayTo). If periodic_limits is omitted entirely for PayTo, this defaults to flexible.
        - `max_total_amount` integer, nullable: The maximum total amount that can be charged for all payments in this periodic limit, in the lowest denomination for the currency (e.g. pence in GBP, cents in EUR). _Note:_ Required for VRP. This is not permitted for the PayTo scheme.
        - `max_payments` integer, nullable: The maximum number of payments that can be collected in this periodic limit. _Note:_ Only supported for the PayTo scheme, where it is optional.
        - `alignment` 'calendar' | 'creation_date': The alignment of the period. Defaults to `creation_date` if not specified. `calendar` - the period follows fixed calendar boundaries, the same for every mandate: `week` runs Monday to Sunday, `month` runs from the 1st to the last day of the calendar month, and `year` runs from 1 January to 31 December. If the mandate starts partway through a period, the limit for that first period is reduced proportionally to the days remaining (e.g. a monthly limit starting on the 15th gives roughly half the limit for that first month). `creation_date` - the period follows the mandate's own start date rather than the calendar. For example, if the mandate starts on the 15th, each monthly period runs from the 15th to the 14th of the following month. The first period is a full period, not reduced proportionally. _Note:_ Has no effect when period is `flexible`.
    - `payment_request_amount` string, nullable: Amount in full.
    - `payment_request_currency` string, nullable: [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217#Active_codes) currency code. `GBP` and `EUR` supported; `GBP` with your customers in the UK and for `EUR` with your customers in supported Eurozone countries only.
    - `payment_request_scheme` string, nullable: (Optional) A scheme used for Open Banking payments. Currently `faster_payments` is supported in the UK (GBP) and `sepa_credit_transfer` and `sepa_instant_credit_transfer` are supported in supported Eurozone countries (EUR). For Eurozone countries, `sepa_credit_transfer` is used as the default. Please be aware that `sepa_instant_credit_transfer` may incur an additional fee for your customer.
    - `payment_request_metadata` BillingRequestTemplatePaymentRequestMetadata, nullable: Key-value store of custom data that will be applied to the payment created when this request is fulfilled. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.
    - `redirect_uri` string, nullable: URL that the payer can be redirected to after completing the request flow.
    - `metadata` BillingRequestTemplateMetadata: Key-value store of custom data. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.

## Response `200`

Successful response

- BillingRequestTemplateSingleResourceResponse
  - `billing_request_templates` BillingRequestTemplate: Billing Request Templates are reusable templates that result in numerous Billing Requests with similar attributes. They provide a no-code solution for generating various types of multi-user payment links. Each template includes a reusable URL that can be embedded in a website or shared with customers via email. Every time the URL is opened, it generates a new Billing Request. Billing Request Templates overcome the key limitation of the Billing Request: a Billing Request cannot be shared among multiple users because it is intended for single-use and is designed to cater to the unique needs of individual customers.
    - `id` string, required: Unique identifier, beginning with "BRT".
    - `name` string, required: Name for the template. Provides a friendly human name for the template, as it is shown in the dashboard. Must not exceed 255 characters.
    - `mandate_request_currency` string, nullable, required: [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217#Active_codes) currency code.
    - `mandate_request_scheme` string, nullable, required: A bank payment scheme. Currently "ach", "autogiro", "bacs", "becs", "becs_nz", "betalingsservice", "faster_payments", "pad", "pay_to" and "sepa_core" are supported. Optional for mandate only requests - if left blank, the payer will be able to select the currency/scheme to pay with from a list of your available schemes.
    - `mandate_request_verify` 'minimum' | 'recommended' | 'when_available' | 'always', nullable, required: Verification preference for the mandate. One of: - `minimum`: only verify if absolutely required, such as when part of scheme rules - `recommended`: in addition to `minimum`, use the GoCardless payment intelligence solution to decide if a payer should be verified - `when_available`: if verification mechanisms are available, use them - `always`: as `when_available`, but fail to create the Billing Request if a mechanism isn't available By default, all Billing Requests use the `recommended` verification preference. It uses GoCardless payment intelligence solution to determine if a payer is fraudulent or not. The verification mechanism is based on the response and the payer may be asked to verify themselves. If the feature is not available, `recommended` behaves like `minimum`. If you never wish to take advantage of our reduced risk products and Verified Mandates as they are released in new schemes, please use the `minimum` verification preference. See [Billing Requests: Creating Verified Mandates](https://docs.gocardless.com/docs/collect-payments/setting-up-mandates/verified-mandates) for more information.
    - `mandate_request_metadata` BillingRequestTemplateMandateRequestMetadata, nullable, required: Key-value store of custom data that will be applied to the mandate created when this request is fulfilled. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.
    - `payment_request_description` string, nullable, required: A human-readable description of the payment and/or mandate. This will be displayed to the payer when authorising the billing request.
    - `mandate_request_description` string, nullable, required: A human-readable description of the payment and/or mandate. This will be displayed to the payer when authorising the billing request.
    - `mandate_request_constraints` BillingRequestTemplateMandateRequestConstraints, nullable, required: Constraints that will apply to the mandate_request. (Optional) Specifically required for PayTo and VRP.
      - `start_date` string, nullable: The date from which payments can be taken. This is an optional field and if it is not supplied the start date will be set to the day authorisation happens.
      - `end_date` string, nullable: The latest date at which payments can be taken, must occur after start_date if present This is an optional field and if it is not supplied the agreement will be considered open and will not have an end date. Keep in mind the end date must take into account how long it will take the user to set up this agreement via the Billing Request.
      - `max_amount_per_payment` integer: The maximum amount that can be charged for a single payment in the lowest denomination for the currency (e.g. pence in GBP, cents in EUR). _Note:_ Required for PayTo and VRP.
      - `payment_method` string: A constraint where you can specify info (free text string) about how payments are calculated. For use when payments vary and cannot be expressed as a fixed amount and frequency. _Note:_ This is only supported for ACH and PAD schemes.
      - `periodic_limits` object[]: Caps on the total amount and/or number of payments that can be collected within a repeating period (e.g. no more than a set amount per month), as opposed to `max_amount_per_payment` which caps a single payment. _Note:_ Required for VRP, where exactly one periodic limit must be provided. Optional for PayTo.
        - `period` 'day' | 'week' | 'month' | 'year' | 'flexible': The repeating period for this mandate. Required whenever a periodic limit is provided (for both VRP and PayTo). If periodic_limits is omitted entirely for PayTo, this defaults to flexible.
        - `max_total_amount` integer, nullable: The maximum total amount that can be charged for all payments in this periodic limit, in the lowest denomination for the currency (e.g. pence in GBP, cents in EUR). _Note:_ Required for VRP. This is not permitted for the PayTo scheme.
        - `max_payments` integer, nullable: The maximum number of payments that can be collected in this periodic limit. _Note:_ Only supported for the PayTo scheme, where it is optional.
        - `alignment` 'calendar' | 'creation_date': The alignment of the period. Defaults to `creation_date` if not specified. `calendar` - the period follows fixed calendar boundaries, the same for every mandate: `week` runs Monday to Sunday, `month` runs from the 1st to the last day of the calendar month, and `year` runs from 1 January to 31 December. If the mandate starts partway through a period, the limit for that first period is reduced proportionally to the days remaining (e.g. a monthly limit starting on the 15th gives roughly half the limit for that first month). `creation_date` - the period follows the mandate's own start date rather than the calendar. For example, if the mandate starts on the 15th, each monthly period runs from the 15th to the 14th of the following month. The first period is a full period, not reduced proportionally. _Note:_ Has no effect when period is `flexible`.
    - `payment_request_amount` string, nullable, required: Amount in full.
    - `payment_request_currency` string, nullable, required: [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217#Active_codes) currency code. `GBP` and `EUR` supported; `GBP` with your customers in the UK and for `EUR` with your customers in supported Eurozone countries only.
    - `payment_request_scheme` string, nullable, required: (Optional) A scheme used for Open Banking payments. Currently `faster_payments` is supported in the UK (GBP) and `sepa_credit_transfer` and `sepa_instant_credit_transfer` are supported in supported Eurozone countries (EUR). For Eurozone countries, `sepa_credit_transfer` is used as the default. Please be aware that `sepa_instant_credit_transfer` may incur an additional fee for your customer.
    - `payment_request_metadata` BillingRequestTemplatePaymentRequestMetadata, nullable, required: Key-value store of custom data that will be applied to the payment created when this request is fulfilled. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.
    - `redirect_uri` string, nullable, required: URL that the payer can be redirected to after completing the request flow.
    - `authorisation_url` string, required: Permanent URL that customers can visit to allow them to complete a flow based on this template, before being returned to the `redirect_uri`.
    - `metadata` BillingRequestTemplateMetadata, required: Key-value store of custom data. Up to 3 keys are permitted, with key names up to 50 characters and values up to 500 characters.
    - `created_at` string, date-time, required: Fixed [timestamp](https://docs.gocardless.com/docs/api-reference/data-conventions#dates-and-times), recording when this resource was created.
    - `updated_at` string, date-time, required: Dynamic [timestamp](https://docs.gocardless.com/docs/api-reference/data-conventions#dates-and-times) recording when this resource was last updated.

## Other responses

- `400`: Bad Request
- `401`: Unauthorised
- `404`: Not found
- `422`: Validation Error
- `500`: Internal Error

---

[API](https://skmtc.dev/gocardless/apis/gocardless-api.md) - [All operations](https://skmtc.dev/gocardless/apis/gocardless-api/llms.txt) - [OpenAPI document](https://skmtc.dev/gocardless/apis/gocardless-api/revisions/4dd3dae45364?raw)