Libraries tagged by http fields

A time picker field for SilverStripe based on the jQuery UI Timepicker By François Gélinas http://fgelinas.com/code/timepicker/

Go to Download

# Introduction The Congressus API allows you to interact with your Congressus administration. The API is RESTful and uses JSON to transport information. This documentation aims to get you started with your first requests. Make sure to read this introduction completely to know all aspects of our API. ## REST basics A REST API describes the resources you can access in a clearly defined path structure. This documentation contains a reference for each resource in the API. Before you can use these resources, you need to know the basics of accessing the Congressus REST API. **Paths and versioning** The Congressus API resides on the following paths: https://api.congressus.nl/ `version` / `resource_path` ? `query_params` - The `version` part of the path indicates the version of the API you want to use. At this moment version v30 is the current version. By pointing to a specific version, we can make sure you always can expect equal behaviour from our API. - The `resource_path` part indicates the path of the resource you want to access. Specific paths to resources can be found in the API documentation. Examples of resource paths are: /members to retrieve all members or /member/ `obj_id` /statuses to create new member status for a member. - The `query_params` contains all filtering, ordering and pagination information. ## Authentication The current authentication flow present at Congressus API is by the use of the Bearer Token suggested by OAuth 2.0. To interact with the Congressus API, you must authenticate by supplying the header `Authorization` with the value `Bearer {access_token}`. **How do I get an API key?** You can create new apps and API keys in Congressus Manager through [this link](https://manager.congressus.nl/settings/integrations/apps). ## Requests There are different approaches for making requests to our API. The command line tool [curl](https://curl.se/) is easy and fast for testing our API. When you want to integrate the API into your own software, you can choose to use a general purpose REST library or to [create your own API client library](https://github.com/OpenAPITools/openapi-generator) based on our OpenAPI specs. ## Responses Congressus uses conventional HTTP response codes to indicate success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that resulted from the provided information (e.g. a required parameter was missing or input data was invalid), and codes in the 5xx range indicate an error with the Congressus API. ## Pagination Endpoints returning a list of entities, are paginated to prevent large responses. To control the pagination, you can use the `page` and `page_size` parameters. page determines which page to return (default: 1), page_size controls the amount of entities to return (default: 25, maximum: 100). Each paginated response contains the following information: - `has_prev` bool - `prev_num` int with previous page number - `has next` bool - `next_num` int with next page number - `data` list with results on current page - `total` int with total number of results ## Filtering Most list endpoints support filtering to get a subset of the available information. Filtering is done using the query. For some filter attributes, filtering for multiple options is supported by adding the `=` multiple times. E.g. `category_id=1&category_id=2`. ### Filtering on period For some resources, a period filter is available. This filter is used to get a subset of the available information within a certain period. The period filter is used by adding the `period_filter` query parameter to the endpoint. **Absolute periods** Absolute periods are defined by exact dates. The format is `YYYY(MM(DD))`. E.g. `2024` or `202402` or `20240227`. A different end date can be given by adding `..` and the end date. E.g. `202402..202403` for the period February 2024 to March 2024. **Relative periods** Relative periods are defined by a period in the past or future. Multiple formats are supported: - `today` - today's date - `yesterday` - yesterday's date - `tomorrow` - tomorrow's date - `(last/this/next)_(day/month/quarter/half_year/year)` - e.g. `last_month` or `next_year` or `this_quarter` - `last_x_days` - e.g. `last_7_days` or `last_14_days` ## Ordering Most list endpoints support ordering on one or more attributes. The order is defined using the `order=` parameter in the query part of the endpoint. Multiple columns can be used for ordering, delimited by a comma. E.g. `order=lastname,initials,first_name`. Each attribute used in the order parameter could be extended with a sort property `:`. E.g. `order=lastname:desc`. The following properties are supported throughout our API: - ```:asc``` ASC NULLS LAST (default) [comment]: (- ```:asc_nulls_last``` ASC NULLS LAST) [comment]: (- ```:asc_nulls_first``` ASC NULLS FIRST) - ```:desc``` DESC NULLS FIRST [comment]: (- ```:desc_nulls_last``` DESC NULLS LAST) [comment]: (- ```:desc_nulls_first``` DESC NULLS FIRST) ## Searching and location filtering For some resources a dedicated /search endpoint is available, which is optimized for searching large datasets. We use an Elasticsearch database to deliver these results. The schema for these resources is often a concise version of the schema used for regular endpoints, but always contains the primary key (obj_id). If you need the full schema for a resource found through /search, you can perform an additional call to the GET / endpoint. In most cases, searching has the following query parameters: - `term` - generic term used for the search - `city` or `zip` - a city name or postal code (only Dutch postal codes allowed) - `distance` - distance from the center of the given city or zip (default *5km*) Results from /search endpoints do not support custom ordering, but are ordered based on relevance (i.e. *score* for term queries and *distance* for all location bound search queries). ## Rate limiting Usage of the Congressus API is unlimited within the plan and permissions of the account you are using. To prevent fraud and abuse, requests to the API are throttled. You can request the API 60 times each minute and 1000 times per hour. The API will respond with a **429 Too many requests** response. This response contains the following fields in the headers: - `X-RateLimit-Limit` The total number of requests allowed for the active window - `X-RateLimit-Remaining` The number of requests remaining in the active window. - `X-RateLimit-Reset` UTC seconds since epoch when the window will be reset. - `Retry-After` Seconds to retry after when the Rate Limit will be reset. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with W3C spec. This allows cross-domain communication from the browser. All responses have a wildcard same-origin, which allows to use our API from any domain or server. # Webhooks Information in a Congressus administration is constantly changing. If you want to perform actions based on these changes, webhooks help you to achieve this. Instead of querying the API at a certain interval, Congressus will notify you about changes to information in the administration. ## Usage Webhooks are useful in a broad range of situations. When the state of an resource changes, Congressus will perform a HTTP request to the URL you provide. Based on the payload of the request, you can determine which action you need to perform. How it works: - You need a URL that Congressus can call to deliver the payload. The Congressus servers must be able to access this URL. - You can add HTTP basic authentication or other token authentication in the URL, as long as the URL stays valid. - Your URL always needs to respond with a 200 HTTP status. Upon registration this is checked. - When your URL responds with another HTTP status code, Congressus will retry to deliver the call 10 times. The time interval between retries is gradually extended. - After each call, Congressus will store the last HTTP status code and HTTP body. Using the webhooks API, you can retrieve this information for debugging purposes. - You can register as many webhooks as required in an administration. Registration is done by sending a POST request to the webhooks API. > **We strongly recommend that you use a secure HTTPS endpoint for receiving payload from Congressus. If you use > unencrypted HTTP, anyone on the network may be able to listen in on sensitive information like members and invoices.** ## Webhook events Each webhook subscribes to an event. When an event occurs, Congressus will call the webhook using an HTTP request to the provided URL. The following events are available: **Members** - member - All member related events - member_added - Member added to the administration - member_updated - Existing Member is updated - member_deleted - Member is removed from the administration - member_birthday - Triggered once on the birthday of a member **Events** - event - All event related events - event_added - Event added - event_updated - Event updated - event_deleted - Event deleted from the administration **Event participations** - event_participation - All event participation related events - event_participation_added - Event participation added - event_participation_updated - Event participation updated - event_participation_deleted - Event participation deleted from the administration **Form entries** - form_entry - All form entry related events - form_entry_added - Form entry added - form_entry_updated - Form entry updated - form_entry_deleted - Form entry deleted from the administration **Sale invoices** - sale_invoices - All sale invoice related events - sale_invoices_added - Sale invoice added - sale_invoices_updated - Sale invoice updated - sale_invoices_deleted - Sale invoice deleted from the administration ## Payload Each webhook call has a payload based on the category of the event that triggered the webhook. E.g. events in the category **Members** get a payload based on the schema for Members, filled with the data for the resource that triggered the webhook. Each webhook call contains the following information: - `webhook_id`- The id of the webhook that triggered the call - `webhook_event` - The category of events for the webhook - `webhook_event_trigger` - The trigger that caused the webhook call - `created` - Date and time at which the webhook was triggered - `data` - List which contains the payload(s) in the form of the complete resource that triggered the event # Changelog This is version 3.0 of the Congressus API. In this chapter we describe all changes in v3.0. ## 2025-09-30 Endpoint for Filters added - A new endpoint `/filters` is added to retrieve available filters for Members, Events and Organisations. ## 2025-08-13 Filter on folder_id added to Storage - The `folder_id` parameter is added to the `storage` endpoint. This allows you to filter storage resources by folder. ## 2025-07-11 Website added to Magic link endpoint - The `website_id` parameter is added to the `magic-links` endpoint. This allows you to create magic links for a specific website. ## 2025-05-24 Organisation resource improvements - `Organisation` resources now also have the 'published' attribute. - `Organisation` resources now also include custom field data in the `custom_field_data` attribute. - Custom fields are defined per organisation category, so the custom fields available for an organisation depend on the category of the organisation. - `Organisation category` resources now also include metadata for the custom fields available for that category in the `custom_fields` attribute. ## 2025-05-04 Magic links added - `Magic links` are added to the API. These links can be used to authenticate a website visitor without the need for a password. ## 2024-11-25 Form and Form entry resources added - `Form` and `Form entry` resources are added to the API. - `Form` resources can be created and updated through the API. It is currently not possible to delete a form or manage fields and fieldsets. - `forms//entries` endpoint is available to retrieve form entries. - `forms//fields` endpoint is available to retrieve form fields. ## 2024-04-23 Custom fields for Members available in PUT/POST requests - Custom fields for Members can now be added or updated through the API. The custom fields are available in the `custom_field_data` attribute of the Member resource. - The old `custom_fields` attribute is deprecated and will be removed in a future version. - The `members/custom-fields` resource shows the available custom fields for Members, including meta information. ## 2024-02-27 Action endpoints for EventParticipation added - `EventParticipation` status can now be changed through the API, including fines when unsubscribing or declining a participation. - API upgrade guide from v20 to v30 removed from docs, as it is no longer relevant. The v20 API is unavailable since mid 2023. ## 2022-12-09 Event ticket types endpoints - `EventTicketType` resources can now be created, updated and deleted through the API - The context is now applied at row level according to the status of the Member for the `v30/members` endpoint ## 2022-06-28 Events updated, MembershipStatus resources added - `Event` resources are now fully operational, including the possibility to add participants / sell tickets through the API. - `MembershipStatus` is now available for Member resources. ## 2022-06-22 Minor updates and fixes - Feat: /members can be filtered against multiples statuses with the status_id query parameter (i.e: /members?status_id=2&status_id=3). - Feat: the News model now contains a list of websites where the news item is published on - Fix: add the default website to POST /news on create - Fix: sale_invoice_id is now honored when given by the creation of a sale invoice /sale-invoices//send ## 2022-06-03 Minor updates and fixes - Feat: Additional filtering for /sale-invoices endpoint added (invoice_type 'debit', 'is_credited' and 'is_not_credited'). - Feat: Renamed /groups/folders endpoints to /group-folders for more consistency. Deprecated old endpoints. - Feat: Added member status resources through /member-statuses. - Feat: Added profile_picture and formal_picture to Member resources. - Fix: we incorrectly used 'per_page' as parameter in the Pagination-section of these docs. The correct parameter is **'page_size'**. - Fix: all non-recursive endpoints for Group folders and Product folders returned children, this is resolved. ## 2022-05-03 Member validation through context added - Added extended validation options for Member-resources by setting a `context` parameter. This context ensures validation according to the field settings as set in Congressus Manager for the member status. - Description for Context validation added to the Member-resources. - Introduction on Context validation added to the [upgrade guide](#section/Upgrading-from-v20-to-v30) ## 2022-04-22 Upgrade guide from v20 to v30 added - First version for the [upgrade guide](#section/Upgrading-from-v20-to-v30) added ## 2022-03-23 Additional filtering for Group and Organisation resources - `Group` and `Group membership` resources can use a filter on member_id - `Organisation` and `Organisation membership` resources can use a filter on member_id ## 2022-03-21 Group and GroupFolder resources added - Group, GroupFolder and GroupMembership resources are added to the API. - `Group folders` are added and use a tree-like structure. - `Organisation` resources have create, update and delete views added. - `Organisation membership` resources are added - Fix: SDD mandates returned and empty list for Member resources. ## 2021-10-14 Organisation resources added - Both Organisation and Organisation category resources are added to the API. ## 2021-10-02 Additional filters added for Event participations - `Event participations` have additional filter functionality ## 2021-09-22 Added resources for Product folders and Sale invoice workflows - `Product folders` are added, using a tree-like structure. - `Sale invoice workflows` are added as resource. Read-only for this moment. - Updated descriptions for Sale invoice attributes. ## 2021-08-09 additional filters for events and products - Events can now be filtered on published true/false - Products can now be filtered on published and folder_id. More than one folder_id can be given by supplying it more than once as query param, e.g. `products?folder_id=123&folder_id=456` ## 2021-08-04 custom fields and descriptions added, publication options added to events and blogs - The retrieve member resource now also shows the custom field information for a member - Many attributes have an additional description added - Publication attributes are added to Event and Blog resources ## 2021-06-09 website related resources added - Website and Webpage resources added (list and get only) - News resources added - Default order is added for Websites, Webpages, Events and News list endpoints. You can overwrite the default order with the `order` query param - Improved descriptions for several resources, removed some typo's in the documentation ## 2021-04-06 initial release - This initial release contains a minor set of resources to work with.

Go to Download

**Send emails fast and with confidence through our easy to use [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) API interface.** # Overview This is the API interface to the [Mail Baby](https://mail.baby/) Mail services provided by [InterServer](https://www.interserver.net). To use this service you must have an account with us at [my.interserver.net](https://my.interserver.net). # Mail Orders Every sending account in MailBaby is backed by a **Mail Order** — a provisioned sending credential with a numeric `id` and a corresponding SMTP username (`mb`). Most calls accept an optional `id` parameter; when omitted the API automatically selects the first active order on your account. Use `GET /mail` to list all orders, and `GET /mail/{id}` to inspect a single order including its current SMTP password. # Sending Email Three sending methods are available depending on your use-case: | Endpoint | Best for | |----------|----------| | `POST /mail/send` | Simple single-recipient messages | | `POST /mail/advsend` | Multiple recipients, CC/BCC, attachments, named contacts | | `POST /mail/rawsend` | Pre-built RFC 822 messages (e.g. DKIM-signed payloads) | After a successful send each endpoint returns a `GenericResponse` whose `text` field contains the **transaction ID** assigned by the relay. This ID can later be matched against entries in `GET /mail/log` via the `mailid` query parameter. # Filtering & Logs `GET /mail/log` provides paginated access to every message accepted by the relay for your account. Combine any of the query parameters to narrow results — e.g. `from`, `to`, `subject`, `messageId`, `origin`, `mx`, `startDate`/`endDate`, and `delivered`. # Blocking Two independent mechanisms exist for suppressing unwanted email: - **Block lists** (`GET /mail/blocks`, `POST /mail/blocks/delete`) — addresses flagged by the system spam filters (LOCAL_BL_RCPT / MBTRAP rules in rspamd, and suspicious subjects). - **Deny rules** (`GET /mail/rules`, `POST /mail/rules`, `DELETE /mail/rules/{ruleId}`) — custom rules you configure to reject specific senders, domains, destination addresses, or subject-line prefixes before a message is even attempted. # Authentication In order to use most of the API calls you must pass credentials from the [my.interserver.net](https://my.interserver.net/) site. We support several different authentication methods but the preferred method is to use the **API Key** which you can get from the [Account Security](https://my.interserver.net/account_security) page. Pass your key in the `X-API-KEY` HTTP request header for every protected call.

Go to Download

The Inter TT REST API is described using OpenAPI 3.0. The descriptor for the api can be downloaded in both [YAML](http://localhost:8080/cyclos/api/openapi.yaml) or [JSON](http://localhost:8080/cyclos/api/openapi.json) formats. These files can be used in tools that support the OpenAPI specification, such as the [OpenAPI Generator](https://openapi-generator.tech). In the API, whenever some data is referenced, for example, a group, or payment type, either id or internal name can be used. When an user is to be referenced, the special word 'self' (sans quotes) always refers to the currently authenticated user, and any identification method (login name, e-mail, mobile phone, account number or custom field) that can be used on keywords search (as configured in the products) can also be used to identify users. Some specific data types have other identification fields, like accounts can have a number and payments can have a transaction number. This all depends on the current configuration. ----------- Most of the operations that return data allow selecting which fields to include in the response. This is useful to avoid calculating data that finally won't be needed and also for reducing the transfer over the network. If nothing is set, all object fields are returned. Fields are handled in 3 modes. Given an example object `{"a": {"x": 1, "y": 2, "z": 3}, "b": 0}`, the modes are: - **Include**: the field is unprefixed or prefixed with `+`. All fields which are not explicitly included are excluded from the result. Examples: - `["a"]` results in `{"a": {"x": 1, "y": 2, "z": 3}}` - `["+b"]` results in `{"b": 0}` - `["a.x"]` results in `{"a": {"x": 1}}`. This is a nested include. At root level, includes only `a` then, on `a`'s level, includes only `x`. - **Exclude**: the field is prefixed by `-` (or, for compatibility purposes, `!`). Only explicitly excluded fields are excluded from the result. Examples: - `["-a"]` results in `{"b": 0}` - `["-b"]` results in `{"a": {"x": 1, "y": 2, "z": 3}}` - `["a.-x"]` results in `{"a": {"y": 2, "z": 3}}`. In this example, `a` is actually an include at the root level, hence, excludes `b`. - **Nested only**: when a field is prefixed by `*` and has a nested path, it only affects includes / excludes for the nested fields, without affecting the current level. Only nested fields are configured. Examples: - `["*a.x"]` results in `{"a": {"x": 1}, "b": 0}`. In this example, `a` is configured to include only `x`. `b` is also included because, there is no explicit includes at root level. - `["*a.-x"]` results in `{"a": {"y": 2, "z": 3}, "b": 0}`. In this example, `a` is configured to exclude only `x`. `b` is also included because there is no explicit includes at the root level. For backwards compatibility, this can also be expressed in a special syntax `-a.x`. Also, keep in mind that `-x.y.z` is equivalent to `*x.*y.-z`. You cannot have the same field included and excluded at the same time - a HTTP `422` status will be returned. Also, when mixing nested excludes with explicit includes or excludes, the nested exclude will be ignored. For example, using `["*a.x", "a.y"]` will ignore the `*a.x` definition, resulting in `{"a": {"y": 2}}`. ----------- For details of the deprecated elements (operations and model) please visit the [deprecation notes page](https://documentation.cyclos.org/4.16.3/api-deprecation.html) for this version.

Go to Download

The following pages give you some general information on how to use our APIs.The actual API services documentation then follows further below. You can use the menu to jump between API sections.This page has a built-in HTTP(S) client, so you can test the services directly from within this page, by filling in the request parameters and/or body in the respective services, and then hitting the TRY button. Note that you need to be authorized to make a successful API call. To authorize, refer to the 'Authorization' section of Access, or in case you already have a valid user token, just use the QUICK AUTH on the left.Please also remember that all user management functions should be looked up in Access.You should also check out the Web Form 2.0 Public Documentation as well as Access Public Documentation for more information. If you need any help with the API, contact [email protected] informationRequest IDsWith any API call, you can pass a request ID via a header with name "X-Request-Id". The request ID can be an arbitrary string with up to 255 characters. Passing a longer string will result in an error.If you don't pass a request ID for a call, finAPI will generate a random ID internally.The request ID is always returned back in the response of a service, as a header with name "X-Request-Id".We highly recommend to always pass a (preferably unique) request ID, and include it into your client application logs whenever you make a request or receive a response(especially in the case of an error response). finAPI is also logging request IDs on its end. Having a request ID can help the finAPI support team to work more efficiently and solve tickets faster.Type CoercionIn order to ease the integration for some languages, which do not natively support high precision number representations, Web Form 2.0 API supports relax type binding for the openAPI type number, which is used for money amount fields. If you use one of those languages, to avoid precision errors that can appear from float values, you can pass the amount as a string.FAQIs there a finAPI SDK?Currently we do not offer a native SDK, but there is the option to generate an SDKfor almost any target language via OpenAPI. Use the 'Download SDK' button on this page for SDK generation.Why do I need to keep authorizing when calling services on this page?This page is a "one-page-app". Reloading the page resets the OAuth authorization context. There is generally no need to reload the page, so just don't do it and your authorization will persist.

Go to Download

RESTful API for Account Information Services (AIS) and Payment Initiation Services (PIS) Application Version: 2.29.4 The following pages give you some general information on how to use our APIs. The actual API services documentation then follows further below. You can use the menu to jump between API sections. This page has a built-in HTTP(S) client, so you can test the services directly from within this page, by filling in the request parameters and/or body in the respective services, and then hitting the TRY button. Note that you need to be authorized to make a successful API call. To authorize, refer to the 'Authorization' section of the API, or just use the OAUTH button that can be found near the TRY button. General information Error Responses When an API call returns with an error, then in general it has the structure shown in the following example: { "errors": [ { "message": "Interface 'FINTS_SERVER' is not supported for this operation.", "code": "BAD_REQUEST", "type": "TECHNICAL" } ], "date": "2020-11-19T16:54:06.854+01:00", "requestId": "selfgen-312042e7-df55-47e4-bffd-956a68ef37b5", "endpoint": "POST /api/v2/bankConnections/import", "authContext": "1/21", "bank": "DEMO0002 - finAPI Test Redirect Bank (id: 280002, location: none)" } If an API call requires an additional authentication by the user, HTTP code 510 is returned and the error response contains the additional "multiStepAuthentication" object, see the following example: { "errors": [ { "message": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "code": "ADDITIONAL_AUTHENTICATION_REQUIRED", "type": "BUSINESS", "multiStepAuthentication": { "hash": "678b13f4be9ed7d981a840af8131223a", "status": "CHALLENGE_RESPONSE_REQUIRED", "challengeMessage": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "answerFieldLabel": "TAN", "redirectUrl": null, "redirectContext": null, "redirectContextField": null, "twoStepProcedures": null, "photoTanMimeType": null, "photoTanData": null, "opticalData": null, "opticalDataAsReinerSct": false } } ], "date": "2019-11-29T09:51:55.931+01:00", "requestId": "selfgen-45059c99-1b14-4df7-9bd3-9d5f126df294", "endpoint": "POST /api/v2/bankConnections/import", "authContext": "1/18", "bank": "DEMO0001 - finAPI Test Bank" } An exception to this error format are API authentication errors, where the following structure is returned: { "error": "invalid_token", "error_description": "Invalid access token: cccbce46-xxxx-xxxx-xxxx-xxxxxxxxxx" } Paging API services that may potentially return a lot of data implement paging. They return a limited number of entries within a "page". Further entries must be fetched with subsequent calls. Any API service that implements paging provides the following input parameters: • "page": the number of the page to be retrieved (starting with 1). • "perPage": the number of entries within a page. The default and maximum value is stated in the documentation of the respective services. A paged response contains an additional "paging" object with the following structure: { ... , "paging": { "page": 1, "perPage": 20, "pageCount": 234, "totalCount": 4662 } } Internationalization The finAPI services support internationalization which means you can define the language you prefer for API service responses. The following languages are available: German, English, Czech, Slovak. The preferred language can be defined by providing the official HTTP Accept-Language header. finAPI reacts on the official iso language codes "de", "en", "cs" and "sk" for the named languages. Additional subtags supported by the Accept-Language header may be provided, e.g. "en-US", but are ignored. If no Accept-Language header is given, German is used as the default language. Exceptions: • Bank login hints and login fields are only available in the language of the bank and not being translated. • Direct messages from the bank systems typically returned as BUSINESS errors will not be translated. • BUSINESS errors created by finAPI directly are available in German and English. • TECHNICAL errors messages meant for developers are mostly in English, but also may be translated. Request IDs With any API call, you can pass a request ID via a header with name "X-Request-Id". The request ID can be an arbitrary string with up to 255 characters. Passing a longer string will result in an error. If you don't pass a request ID for a call, finAPI will generate a random ID internally. The request ID is always returned back in the response of a service, as a header with name "X-Request-Id". We highly recommend to always pass a (preferably unique) request ID, and include it into your client application logs whenever you make a request or receive a response (especially in the case of an error response). finAPI is also logging request IDs on its end. Having a request ID can help the finAPI support team to work more efficiently and solve tickets faster. Overriding HTTP methods Some HTTP clients do not support the HTTP methods PATCH or DELETE. If you are using such a client in your application, you can use a POST request instead with a special HTTP header indicating the originally intended HTTP method. The header's name is X-HTTP-Method-Override. Set its value to either PATCH or DELETE. POST Requests having this header set will be treated either as PATCH or DELETE by the finAPI servers. Example: X-HTTP-Method-Override: PATCH POST /api/v2/label/51 {"name": "changed label"} will be interpreted by finAPI as: PATCH /api/v2/label/51 {"name": "changed label"} User metadata With the migration to PSD2 APIs, a new term called "User metadata" (also known as "PSU metadata") has been introduced to the API. This user metadata aims to inform the banking API if there was a real end-user behind an HTTP request or if the request was triggered by a system (e.g. by an automatic batch update). In the latter case, the bank may apply some restrictions such as limiting the number of HTTP requests for a single consent. Also, some operations may be forbidden entirely by the banking API. For example, some banks do not allow issuing a new consent without the end-user being involved. Therefore, it is certainly necessary and obligatory for the customer to provide the PSU metadata for such operations. As finAPI does not have direct interaction with the end-user, it is the client application's responsibility to provide all the necessary information about the end-user. This must be done by sending additional headers with every request triggered on behalf of the end-user. At the moment, the following headers are supported by the API: • "PSU-IP-Address" - the IP address of the user's device. It has to be an IPv4 address, as some banks cannot work with IPv6 addresses. If a non-IPv4 address is passed, we will replace the value with our own IPv4 address as a fallback. • "PSU-Device-OS" - the user's device and/or operating system identification. • "PSU-User-Agent" - the user's web browser or other client device identification. FAQ Is there a finAPI SDK? Currently we do not offer a native SDK, but there is the option to generate an SDK for almost any target language via OpenAPI. Use the 'Download SDK' button on this page for SDK generation. How can I enable finAPI's automatic batch update? Currently there is no way to set up the batch update via the API. Please contact [email protected] for this. Why do I need to keep authorizing when calling services on this page? This page is a "one-page-app". Reloading the page resets the OAuth authorization context. There is generally no need to reload the page, so just don't do it and your authorization will persist.

Go to Download

# Introduction The Congressus API allows you to interact with your Congressus administration. The API is RESTful and uses JSON to transport information. This documentation aims to get you started with your first requests. Make sure to read this introduction completely to know all aspects of our API. ## REST basics A REST API describes the resources you can access in a clearly defined path structure. This documentation contains a reference for each resource in the API. Before you can use these resources, you need to know the basics of accessing the Congressus REST API. **Paths and versioning** The Congressus API resides on the following paths: https://api.congressus.nl/ `version` / `resource_path` ? `query_params` - The `version` part of the path indicates the version of the API you want to use. At this moment version v30 is the current version. By pointing to a specific version, we can make sure you always can expect equal behaviour from our API. - The `resource_path` part indicates the path of the resource you want to access. Specific paths to resources can be found in the API documentation. Examples of resource paths are: /members to retrieve all members or /member/ `obj_id` /statuses to create new member status for a member. - The `query_params` contains all filtering, ordering and pagination information. ## Authentication The current authentication flow present at Congressus API is by the use of the Bearer Token suggested by OAuth 2.0. To interact with the Congressus API, you must authenticate by supplying the header `Authorization` with the value `Bearer {access_token}`. **How do I get an API key?** You can create new apps and API keys in Congressus Manager through [this link](https://manager.congressus.nl/settings/integrations/apps). ## Requests There are different approaches for making requests to our API. The command line tool [curl](https://curl.se/) is easy and fast for testing our API. When you want to integrate the API into your own software, you can choose to use a general purpose REST library or to [create your own API client library](https://github.com/OpenAPITools/openapi-generator) based on our OpenAPI specs. ## Responses Congressus uses conventional HTTP response codes to indicate success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that resulted from the provided information (e.g. a required parameter was missing or input data was invalid), and codes in the 5xx range indicate an error with the Congressus API. ## Pagination Endpoints returning a list of entities, are paginated to prevent large responses. To control the pagination, you can use the `page` and `page_size` parameters. page determines which page to return (default: 1), page_size controls the amount of entities to return (default: 25, maximum: 100). Each paginated response contains the following information: - `has_prev` bool - `prev_num` int with previous page number - `has next` bool - `next_num` int with next page number - `data` list with results on current page - `total` int with total number of results ## Filtering Most list endpoints support filtering to get a subset of the available information. Filtering is done using the query. For some filter attributes, filtering for multiple options is supported by adding the `=` multiple times. E.g. `category_id=1&category_id=2`. ### Filtering on period For some resources, a period filter is available. This filter is used to get a subset of the available information within a certain period. The period filter is used by adding the `period_filter` query parameter to the endpoint. **Absolute periods** Absolute periods are defined by exact dates. The format is `YYYY(MM(DD))`. E.g. `2024` or `202402` or `20240227`. A different end date can be given by adding `..` and the end date. E.g. `202402..202403` for the period February 2024 to March 2024. **Relative periods** Relative periods are defined by a period in the past or future. Multiple formats are supported: - `today` - today's date - `yesterday` - yesterday's date - `tomorrow` - tomorrow's date - `(last/this/next)_(day/month/quarter/half_year/year)` - e.g. `last_month` or `next_year` or `this_quarter` - `last_x_days` - e.g. `last_7_days` or `last_14_days` ## Ordering Most list endpoints support ordering on one or more attributes. The order is defined using the `order=` parameter in the query part of the endpoint. Multiple columns can be used for ordering, delimited by a comma. E.g. `order=lastname,initials,first_name`. Each attribute used in the order parameter could be extended with a sort property `:`. E.g. `order=lastname:desc`. The following properties are supported throughout our API: - ```:asc``` ASC NULLS LAST (default) [comment]: (- ```:asc_nulls_last``` ASC NULLS LAST) [comment]: (- ```:asc_nulls_first``` ASC NULLS FIRST) - ```:desc``` DESC NULLS FIRST [comment]: (- ```:desc_nulls_last``` DESC NULLS LAST) [comment]: (- ```:desc_nulls_first``` DESC NULLS FIRST) ## Searching and location filtering For some resources a dedicated /search endpoint is available, which is optimized for searching large datasets. We use an Elasticsearch database to deliver these results. The schema for these resources is often a concise version of the schema used for regular endpoints, but always contains the primary key (obj_id). If you need the full schema for a resource found through /search, you can perform an additional call to the GET / endpoint. In most cases, searching has the following query parameters: - `term` - generic term used for the search - `city` or `zip` - a city name or postal code (only Dutch postal codes allowed) - `distance` - distance from the center of the given city or zip (default *5km*) Results from /search endpoints do not support custom ordering, but are ordered based on relevance (i.e. *score* for term queries and *distance* for all location bound search queries). ## Rate limiting Usage of the Congressus API is unlimited within the plan and permissions of the account you are using. To prevent fraud and abuse, requests to the API are throttled. You can request the API 60 times each minute and 1000 times per hour. The API will respond with a **429 Too many requests** response. This response contains the following fields in the headers: - `X-RateLimit-Limit` The total number of requests allowed for the active window - `X-RateLimit-Remaining` The number of requests remaining in the active window. - `X-RateLimit-Reset` UTC seconds since epoch when the window will be reset. - `Retry-After` Seconds to retry after when the Rate Limit will be reset. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with W3C spec. This allows cross-domain communication from the browser. All responses have a wildcard same-origin, which allows to use our API from any domain or server. # Webhooks Information in a Congressus administration is constantly changing. If you want to perform actions based on these changes, webhooks help you to achieve this. Instead of querying the API at a certain interval, Congressus will notify you about changes to information in the administration. ## Usage Webhooks are useful in a broad range of situations. When the state of an resource changes, Congressus will perform a HTTP request to the URL you provide. Based on the payload of the request, you can determine which action you need to perform. How it works: - You need a URL that Congressus can call to deliver the payload. The Congressus servers must be able to access this URL. - You can add HTTP basic authentication or other token authentication in the URL, as long as the URL stays valid. - Your URL always needs to respond with a 200 HTTP status. Upon registration this is checked. - When your URL responds with another HTTP status code, Congressus will retry to deliver the call 10 times. The time interval between retries is gradually extended. - After each call, Congressus will store the last HTTP status code and HTTP body. Using the webhooks API, you can retrieve this information for debugging purposes. - You can register as many webhooks as required in an administration. Registration is done by sending a POST request to the webhooks API. > **We strongly recommend that you use a secure HTTPS endpoint for receiving payload from Congressus. If you use > unencrypted HTTP, anyone on the network may be able to listen in on sensitive information like members and invoices.** ## Webhook events Each webhook subscribes to an event. When an event occurs, Congressus will call the webhook using an HTTP request to the provided URL. The following events are available: **Members** - member - All member related events - member_added - Member added to the administration - member_updated - Existing Member is updated - member_deleted - Member is removed from the administration - member_birthday - Triggered once on the birthday of a member **Events** - event - All event related events - event_added - Event added - event_updated - Event updated - event_deleted - Event deleted from the administration **Event participations** - event_participation - All event participation related events - event_participation_added - Event participation added - event_participation_updated - Event participation updated - event_participation_deleted - Event participation deleted from the administration **Form entries** - form_entry - All form entry related events - form_entry_added - Form entry added - form_entry_updated - Form entry updated - form_entry_deleted - Form entry deleted from the administration **Sale invoices** - sale_invoices - All sale invoice related events - sale_invoices_added - Sale invoice added - sale_invoices_updated - Sale invoice updated - sale_invoices_deleted - Sale invoice deleted from the administration ## Payload Each webhook call has a payload based on the category of the event that triggered the webhook. E.g. events in the category **Members** get a payload based on the schema for Members, filled with the data for the resource that triggered the webhook. Each webhook call contains the following information: - `webhook_id`- The id of the webhook that triggered the call - `webhook_event` - The category of events for the webhook - `webhook_event_trigger` - The trigger that caused the webhook call - `created` - Date and time at which the webhook was triggered - `data` - List which contains the payload(s) in the form of the complete resource that triggered the event # Changelog This is version 3.0 of the Congressus API. In this chapter we describe all changes in v3.0. ## 2025-09-30 Endpoint for Filters added - A new endpoint `/filters` is added to retrieve available filters for Members, Events and Organisations. ## 2025-08-13 Filter on folder_id added to Storage - The `folder_id` parameter is added to the `storage` endpoint. This allows you to filter storage resources by folder. ## 2025-07-11 Website added to Magic link endpoint - The `website_id` parameter is added to the `magic-links` endpoint. This allows you to create magic links for a specific website. ## 2025-05-24 Organisation resource improvements - `Organisation` resources now also have the 'published' attribute. - `Organisation` resources now also include custom field data in the `custom_field_data` attribute. - Custom fields are defined per organisation category, so the custom fields available for an organisation depend on the category of the organisation. - `Organisation category` resources now also include metadata for the custom fields available for that category in the `custom_fields` attribute. ## 2025-05-04 Magic links added - `Magic links` are added to the API. These links can be used to authenticate a website visitor without the need for a password. ## 2024-11-25 Form and Form entry resources added - `Form` and `Form entry` resources are added to the API. - `Form` resources can be created and updated through the API. It is currently not possible to delete a form or manage fields and fieldsets. - `forms//entries` endpoint is available to retrieve form entries. - `forms//fields` endpoint is available to retrieve form fields. ## 2024-04-23 Custom fields for Members available in PUT/POST requests - Custom fields for Members can now be added or updated through the API. The custom fields are available in the `custom_field_data` attribute of the Member resource. - The old `custom_fields` attribute is deprecated and will be removed in a future version. - The `members/custom-fields` resource shows the available custom fields for Members, including meta information. ## 2024-02-27 Action endpoints for EventParticipation added - `EventParticipation` status can now be changed through the API, including fines when unsubscribing or declining a participation. - API upgrade guide from v20 to v30 removed from docs, as it is no longer relevant. The v20 API is unavailable since mid 2023. ## 2022-12-09 Event ticket types endpoints - `EventTicketType` resources can now be created, updated and deleted through the API - The context is now applied at row level according to the status of the Member for the `v30/members` endpoint ## 2022-06-28 Events updated, MembershipStatus resources added - `Event` resources are now fully operational, including the possibility to add participants / sell tickets through the API. - `MembershipStatus` is now available for Member resources. ## 2022-06-22 Minor updates and fixes - Feat: /members can be filtered against multiples statuses with the status_id query parameter (i.e: /members?status_id=2&status_id=3). - Feat: the News model now contains a list of websites where the news item is published on - Fix: add the default website to POST /news on create - Fix: sale_invoice_id is now honored when given by the creation of a sale invoice /sale-invoices//send ## 2022-06-03 Minor updates and fixes - Feat: Additional filtering for /sale-invoices endpoint added (invoice_type 'debit', 'is_credited' and 'is_not_credited'). - Feat: Renamed /groups/folders endpoints to /group-folders for more consistency. Deprecated old endpoints. - Feat: Added member status resources through /member-statuses. - Feat: Added profile_picture and formal_picture to Member resources. - Fix: we incorrectly used 'per_page' as parameter in the Pagination-section of these docs. The correct parameter is **'page_size'**. - Fix: all non-recursive endpoints for Group folders and Product folders returned children, this is resolved. ## 2022-05-03 Member validation through context added - Added extended validation options for Member-resources by setting a `context` parameter. This context ensures validation according to the field settings as set in Congressus Manager for the member status. - Description for Context validation added to the Member-resources. - Introduction on Context validation added to the [upgrade guide](#section/Upgrading-from-v20-to-v30) ## 2022-04-22 Upgrade guide from v20 to v30 added - First version for the [upgrade guide](#section/Upgrading-from-v20-to-v30) added ## 2022-03-23 Additional filtering for Group and Organisation resources - `Group` and `Group membership` resources can use a filter on member_id - `Organisation` and `Organisation membership` resources can use a filter on member_id ## 2022-03-21 Group and GroupFolder resources added - Group, GroupFolder and GroupMembership resources are added to the API. - `Group folders` are added and use a tree-like structure. - `Organisation` resources have create, update and delete views added. - `Organisation membership` resources are added - Fix: SDD mandates returned and empty list for Member resources. ## 2021-10-14 Organisation resources added - Both Organisation and Organisation category resources are added to the API. ## 2021-10-02 Additional filters added for Event participations - `Event participations` have additional filter functionality ## 2021-09-22 Added resources for Product folders and Sale invoice workflows - `Product folders` are added, using a tree-like structure. - `Sale invoice workflows` are added as resource. Read-only for this moment. - Updated descriptions for Sale invoice attributes. ## 2021-08-09 additional filters for events and products - Events can now be filtered on published true/false - Products can now be filtered on published and folder_id. More than one folder_id can be given by supplying it more than once as query param, e.g. `products?folder_id=123&folder_id=456` ## 2021-08-04 custom fields and descriptions added, publication options added to events and blogs - The retrieve member resource now also shows the custom field information for a member - Many attributes have an additional description added - Publication attributes are added to Event and Blog resources ## 2021-06-09 website related resources added - Website and Webpage resources added (list and get only) - News resources added - Default order is added for Websites, Webpages, Events and News list endpoints. You can overwrite the default order with the `order` query param - Improved descriptions for several resources, removed some typo's in the documentation ## 2021-04-06 initial release - This initial release contains a minor set of resources to work with.

Go to Download

Silverstripe select form field that allows to choose from Simple Line Icons (http://graphicburger.com/simple-line-icons-webfont/).

Go to Download

# Summary The **NextGenPSD2** *Framework Version 1.3.6* (with errata) offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] "If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored." The element "Accept" will not be defined in this file at any place. The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 comlient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space

Go to Download

RESTful API for Account Information Services (AIS) and Payment Initiation Services (PIS) The following pages give you some general information on how to use our APIs. The actual API services documentation then follows further below. You can use the menu to jump between API sections. This page has a built-in HTTP(S) client, so you can test the services directly from within this page, by filling in the request parameters and/or body in the respective services, and then hitting the TRY button. Note that you need to be authorized to make a successful API call. To authorize, refer to the 'Authorization' section of the API, or just use the OAUTH button that can be found near the TRY button. General information Error Responses When an API call returns with an error, then in general it has the structure shown in the following example: { "errors": [ { "message": "Interface 'FINTS_SERVER' is not supported for this operation.", "code": "BAD_REQUEST", "type": "TECHNICAL" } ], "date": "2020-11-19 16:54:06.854", "requestId": "selfgen-312042e7-df55-47e4-bffd-956a68ef37b5", "endpoint": "POST /api/v1/bankConnections/import", "authContext": "1/21", "bank": "DEMO0002 - finAPI Test Redirect Bank" } If an API call requires an additional authentication by the user, HTTP code 510 is returned and the error response contains the additional "multiStepAuthentication" object, see the following example: { "errors": [ { "message": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "code": "ADDITIONAL_AUTHENTICATION_REQUIRED", "type": "BUSINESS", "multiStepAuthentication": { "hash": "678b13f4be9ed7d981a840af8131223a", "status": "CHALLENGE_RESPONSE_REQUIRED", "challengeMessage": "Es ist eine zusätzliche Authentifizierung erforderlich. Bitte geben Sie folgenden Code an: 123456", "answerFieldLabel": "TAN", "redirectUrl": null, "redirectContext": null, "redirectContextField": null, "twoStepProcedures": null, "photoTanMimeType": null, "photoTanData": null, "opticalData": null } } ], "date": "2019-11-29 09:51:55.931", "requestId": "selfgen-45059c99-1b14-4df7-9bd3-9d5f126df294", "endpoint": "POST /api/v1/bankConnections/import", "authContext": "1/18", "bank": "DEMO0001 - finAPI Test Bank" } An exception to this error format are API authentication errors, where the following structure is returned: { "error": "invalid_token", "error_description": "Invalid access token: cccbce46-xxxx-xxxx-xxxx-xxxxxxxxxx" } Paging API services that may potentially return a lot of data implement paging. They return a limited number of entries within a "page". Further entries must be fetched with subsequent calls. Any API service that implements paging provides the following input parameters: • "page": the number of the page to be retrieved (starting with 1). • "perPage": the number of entries within a page. The default and maximum value is stated in the documentation of the respective services. A paged response contains an additional "paging" object with the following structure: { ... , "paging": { "page": 1, "perPage": 20, "pageCount": 234, "totalCount": 4662 } } Internationalization The finAPI services support internationalization which means you can define the language you prefer for API service responses. The following languages are available: German, English, Czech, Slovak. The preferred language can be defined by providing the official HTTP Accept-Language header. finAPI reacts on the official iso language codes "de", "en", "cs" and "sk" for the named languages. Additional subtags supported by the Accept-Language header may be provided, e.g. "en-US", but are ignored. If no Accept-Language header is given, German is used as the default language. Exceptions: • Bank login hints and login fields are only available in the language of the bank and not being translated. • Direct messages from the bank systems typically returned as BUSINESS errors will not be translated. • BUSINESS errors created by finAPI directly are available in German and English. • TECHNICAL errors messages meant for developers are mostly in English, but also may be translated. Request IDs With any API call, you can pass a request ID via a header with name "X-Request-Id". The request ID can be an arbitrary string with up to 255 characters. Passing a longer string will result in an error. If you don't pass a request ID for a call, finAPI will generate a random ID internally. The request ID is always returned back in the response of a service, as a header with name "X-Request-Id". We highly recommend to always pass a (preferably unique) request ID, and include it into your client application logs whenever you make a request or receive a response (especially in the case of an error response). finAPI is also logging request IDs on its end. Having a request ID can help the finAPI support team to work more efficiently and solve tickets faster. Overriding HTTP methods Some HTTP clients do not support the HTTP methods PATCH or DELETE. If you are using such a client in your application, you can use a POST request instead with a special HTTP header indicating the originally intended HTTP method. The header's name is X-HTTP-Method-Override. Set its value to either PATCH or DELETE. POST Requests having this header set will be treated either as PATCH or DELETE by the finAPI servers. Example: X-HTTP-Method-Override: PATCH POST /api/v1/label/51 {"name": "changed label"} will be interpreted by finAPI as: PATCH /api/v1/label/51 {"name": "changed label"} User metadata With the migration to PSD2 APIs, a new term called "User metadata" (also known as "PSU metadata") has been introduced to the API. This user metadata aims to inform the banking API if there was a real end-user behind an HTTP request or if the request was triggered by a system (e.g. by an automatic batch update). In the latter case, the bank may apply some restrictions such as limiting the number of HTTP requests for a single consent. Also, some operations may be forbidden entirely by the banking API. For example, some banks do not allow issuing a new consent without the end-user being involved. Therefore, it is certainly necessary and obligatory for the customer to provide the PSU metadata for such operations. As finAPI does not have direct interaction with the end-user, it is the client application's responsibility to provide all the necessary information about the end-user. This must be done by sending additional headers with every request triggered on behalf of the end-user. At the moment, the following headers are supported by the API: • "PSU-IP-Address" - the IP address of the user's device. • "PSU-Device-OS" - the user's device and/or operating system identification. • "PSU-User-Agent" - the user's web browser or other client device identification. FAQ Is there a finAPI SDK? Currently we do not offer a native SDK, but there is the option to generate a SDK for almost any target language via OpenAPI. Use the 'Download SDK' button on this page for SDK generation. How can I enable finAPI's automatic batch update? Currently there is no way to set up the batch update via the API. Please contact [email protected] for this. Why do I need to keep authorizing when calling services on this page? This page is a "one-page-app". Reloading the page resets the OAuth authorization context. There is generally no need to reload the page, so just don't do it and your authorization will persist.

Go to Download

An alternative to https://github.com/filamentphp/spatie-laravel-translatable-plugin. The difference is that all translations occur directly under each field.

Go to Download

Field Date based on https://vcalendar.io/

Go to Download

The payments API is used to create a session to offer Klarna's payment methods as part of your checkout. As soon as the purchase is completed the order should be read and handled using the [`Order Management API`](https://docs.klarna.com/api/ordermanagement). **Note:** Examples provided in this section includes full payloads, including all supported fields , required and optionals. In order to implement a best in class request we recommend you don't include customer details when initiating a payment session. Refer to [Initiate a payment](https://docs.klarna.com/klarna-payments/integrate-with-klarna-payments/step-1-initiate-a-payment/) section for further details. Read more on [Klarna payments](https://docs.klarna.com/klarna-payments/).

Go to Download

Vue Avatar (https://eliep.github.io/vue-avatar/) Field wrapper for Laravel Nova (https://nova.laravel.com/)

Go to Download

This bundle provides easy reCAPTCHA form field integration, this is a fork of https://github.com/excelwebzone/EWZRecaptchaBundle

Go to Download