> ## Documentation Index > Fetch the complete documentation index at: https://docs.yapily.com/llms.txt > Use this file to discover all available pages before exploring further. # Create Event Subscription > Used to subscribe to notifications relating to a specified event type. Learn more: [Webhooks & Notifications](/tools-and-services/webhooks/introduction) ## OpenAPI ````yaml /openapi-converted.json post /notifications/event-subscriptions openapi: 3.0.1 info: description: >- The Yapily API enables connections between your application and users' banks. For more information check out our [documentation](/introduction). In particular, make sure to view our [Getting Started](/getting-started/get-started) steps if this is your first time here. While testing the API, our list of [sandbox credentials](/resources/sandbox/sandbox-credentials) maybe useful. title: Yapily API version: 12.3.4 contact: name: Yapily Support url: https://docs.yapily.com/resources/support email: support@yapily.com servers: - url: https://api.yapily.com security: - basicAuth: [] tags: - description: >- The `Application` is the base entity that is used to interact with the API and contains a collection of `Institution` objects. You can have multiple Applications associated with your account e.g. a production application with live access to each `Institution` and a development application with access to sandboxes. name: Application - description: >- The Users endpoints are used to manage each user (otherwise known as the PSU) in Yapily. Each user belongs to an Application and as a consequence, so do each `Consent` created for a particular `User`. name: Users - description: >- An `Institution` object represents any Account Serving Payment Servicing Provider (ASPSP) that has been integrated and is accessible through the Yapily APIs (ASPSPs are entities that publish Read/Write APIs to permit, with customer consent, payments initiated by third party providers and/or make their customers financial data available to third party providers via their API endpoints). Any one of the following would be represented as Institution: - Traditional banks e.g. Santander - Neo-banks e.g. Monzo - Building societies e.g. Cumberland Building Society name: Institutions - description: >- The Consents endpoints are used to manage each `Consent` created by Yapily in response to an authorisation created for a user. The `Consent` object contains data that identifies a user's consent for a specific `Institution` within a Yapily application. Other than the id of the consent, the `institution-id` for the corresponding `Institution` and the user identifiers (`user-uuid` and `application-user-id`), it contains various details that indicates how the `Consent` can be used. name: Consents - description: >- Before calling [Financial Data](#yapily-api-financial-data) or [Payments](#yapily-api-payments) endpoints, a consent from an end-user must be obtained. Consents are valid for up to 90 days for Financial Data endpoints and have a single-use for Payment endpoints i.e. a new consent must be obtained for each payment. NOTE: A user consent is also referred to as an 'Authorisation'. name: Authorisations - description: >- In order to access a user's Financial Data, you are required to request an [Authorisation](#tag/Authorisations) from the user to share the account information the bank has. Once a `consent-token` is obtained, you can call the necessary Financial Data endpoint(s) to retrieve the user's data. name: Financial Data - description: >- In order to make a Payment on behalf of a user, you are required to request an [Authorisation](#tag/Authorisations) from the user to authorise the user's account to make the payment from. Once a `consent-token` is obtained, you can call the necessary Payments endpoint(s) to execute a payment. name: Payments - description: >+ The Notifications endpoints provide an interactive way for user to receive notifications according to different event-types. This feature is currently in private beta. Please reach out if you require access. name: Notifications - description: >- Variable Recurring Payments enables transfer of money between accounts held by the same person or transfer of money for business payments. In order to make Sweeping Variable Recurring Payments on behalf of a user, you are required to request an [Consent](#tag/Authorisations) from the user by calling the Sweeping Consent endpoint to authorise the user's account to make the payment. Once a `consent-token` is obtained, you can call the Payments endpoint to execute the Sweeping Variable Recurring Payments transaction. Before executing the payment, you have the option to confirm availability of funds in the user's account by calling the Funds Confirmation endpoint. See [VRP Payments](/payments/vrps/additional-information) for more information. name: Variable Recurring Payments - description: Hosted Payment Pages endpoints for payments products name: Hosted Payment Pages - description: Hosted Consent Pages endpoints for data products name: Hosted Consent Pages - description: >- The constraints endpoints can be used to retrieve institution specific data requirements and rules that will apply when performing other operations. name: Constraints - description: >- Application Management endpoints help with creating and managing client sub-applications. name: Application Management - description: 'Data Plus endpoints enable our customers to enrich transaction data. ' name: Data Plus - description: Webhook endpoints name: Webhooks - description: Application Beneficiaries Endpoints name: Application Beneficiaries - description: User Beneficiaries Endpoints name: User Beneficiaries paths: /notifications/event-subscriptions: post: tags: - Notifications summary: Create Event Subscription description: Used to subscribe to notifications relating to a specified event type. operationId: createEventSubscription parameters: - $ref: '#/components/parameters/SubAppHeader' requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/EventSubscriptionRequest' responses: '201': description: Event subscription created successfully content: application/json: schema: $ref: '#/components/schemas/ApiResponseOfEventSubscriptionResponse' '400': description: Bad request for missing required properties '401': description: Unauthorized '409': description: Event subscription already exist for the application components: parameters: SubAppHeader: description: The sub-application ID to which event type is being subscribed to in: header name: sub-application required: false schema: type: string format: uuid schemas: EventSubscriptionRequest: title: Request to create a subscription for notifications type: object required: - eventTypeId - notification properties: eventTypeId: type: string description: >- Unique identifier of the event type (for which notifications will be sent). Allowed values: payment.status, payment.status.completed, payment.isoStatus example: payment.status.completed notification: $ref: '#/components/schemas/Notification' ApiResponseOfEventSubscriptionResponse: type: object properties: meta: $ref: '#/components/schemas/ResponseMeta' data: $ref: '#/components/schemas/EventSubscriptionResponse' links: type: object additionalProperties: type: string forwardedData: type: array items: $ref: '#/components/schemas/ResponseForwardedData' raw: deprecated: true type: array items: $ref: '#/components/schemas/RawResponse' tracingId: type: string writeOnly: true Notification: description: Subscription details for how and where to receive notifications. type: object required: - type - url properties: type: type: string description: >- How the notification will be delivered. This is currently only via WEBHOOK. example: WEBHOOK url: type: string description: URL to which the notification will be sent. example: https://httpbin.com/new_endpoint ResponseMeta: type: object properties: tracingId: type: string EventSubscriptionResponse: title: Response on successful creation of event subscription type: object required: - eventTypeId - applicationId - created - notification properties: eventTypeId: type: string description: >- Unique identifier of the event type (for which notifications will be sent) example: payment.status.completed applicationId: type: string format: uuid description: Application related to event subscription. example: 2698db90-6635-4f76-b673-5ce8e2aeda0e created: type: string description: Creation date of event subscription. example: 28-07-2021 15:47:03 notification: $ref: '#/components/schemas/Notification' ResponseForwardedData: type: object properties: headers: type: object additionalProperties: type: string url: type: string RawResponse: deprecated: true type: object description: >- [DEPRECATED] Interaction (raw request and response) that occurred with the `Institution` in order to fulfil a request. properties: request: $ref: '#/components/schemas/RawRequest' duration: type: string format: iso8601 headers: type: object additionalProperties: type: string resultCode: type: integer format: int32 result: type: object RawRequest: type: object properties: method: type: string url: type: string requestInstant: type: string format: date-time headers: type: object additionalProperties: type: string body: type: object bodyParameters: type: object additionalProperties: type: string startTime: type: string format: date-time startedAt: type: string format: date-time deprecated: true securitySchemes: basicAuth: description: >- Use HTTP Basic Authentication with your Application ID as username and Application Secret as password. Manage credentials in the [Yapily Console](https://console.yapily.com/). See [Authentication](/api-reference/authentication) for details. scheme: basic type: http ````