API Endpoints are characterized as either Consumer or Provider Endpoints. API Consumer Endpoints are automatically created in the CIC Cockpit when Web Service Consumer objects are created in CIC Studio and deployed to the Integration Server. API Provider Endpoints are created in CIC Cockpit and represent the APIs that can be consumed by the user of this endpoint.
Both Endpoint types reflect API requests and responses in your integration. The details of these messages and responses can be viewed from the CIC Cockpit.
Any integration using these Endpoints is driven by the Integration Engine and CIC Studio. API Endpoints are not available to be used in Data Flows in the CIC Cockpit. They are, however, used by CIC Cockpit to display Job information on the Job List page and Job Details page.
API Consumer Endpoints
API Consumer Endpoints (shown below) are auto-generated in the CIC Cockpit when Web Service (WS) Consumer objects are created in CIC Studio and deployed to the Integration Server. Multiple WS Consumer objects referencing the same host and vault alias value (if applicable) are combined into a single API Consumer Endpoint, which can be viewed from the Jobs page.
Changes to API Consumer Endpoints in the CIC Cockpit are limited to renaming only. This type of Endpoint cannot be created or deleted directly from the CIC Cockpit.
API Provider Endpoints
You create API Provider Endpoints in the CIC Cockpit when Web Service (WS) Provider objects have been created in CIC Studio and deployed to the Integration Server.
API Provider Endpoint Attributes
The API Provider Endpoint has the following attributes:
| Attribute | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| APIs |
Displays a list of the APIs selected for this Endpoint. If no APIs have been selected, the Select APIs link is displayed. Click the link to see a list of APIs you can choose from. If a list of APIs is displayed, you can click the Edit button to add or remove APIs from the list. Each line item in the APIs list shows the API name and authentication method. If the authentication method is OAuth2, the Access Token URL field contains the address you would use to obtain an access token. See Using OAuth2 with API Endpoints. The Access Token URL field does not contain any value for an API using Basic Authentication. |
||||||||
| Authentication |
Displays the type of authentication employed for the APIs listed above. The authentication type is defined as part of the API itself. Possible types are Basic, OAuth2, Key-based, and Custom. See Using Basic Authentication with API Endpoints, Using OAuth2 with API Endpoints, or Using Key-based Authentication in API Endpoints. Note: Endpoint authentication is enforced first, and then the IP allowlisting is enforced. If Endpoint authentication is successful but allowlisting fails, the client receives a 403 Forbidden response. |
||||||||
| IP Whitelisting |
Specifies the IP addresses allowed to connect to this API Endpoint. If no IP addresses are specified, CIC allows access to the endpoint from any IP address. IP addresses can be a single address or a range of addresses. Enter addresses or address ranges one per row or separate them using commas. The following are examples of valid IP addresses:
|
Creating an API Provider Endpoint
- Click the New Endpoint icon on the Endpoint screen.
- Specify a Name and select API as the Endpoint Type.
- Click the Select APIs link to display a list of available APIs and select one or more APIs to associate with this Endpoint.
- Specify Authentication attribute values for your Endpoint (see Using Basic Authentication with API Endpoints, Using OAuth2 with API Endpoints, or Using Key-based Authentication in API Endpoints) and in the IP Whitelisting field, specify IP addresses you want to have access to this Endpoint.
- Click Save.
API Provider Rate Limiting
By default, requests to API Providers are subject to a rate limit of 5 requests per API per second. For example, if two APIs are used across multiple Web Service Providers, each API can be invoked 5 times per second. If the rate limit is exceeded, the API responds with a 429 Too Many Requests status code.
Please refer to the API section of Web Service Provider object for information about how to set up an API group for a Web Service Provider.
Best Practices to Avoid Rate Limiting Errors
- If the customer regularly receives a 429-error code, try updating the API Client to distribute requests more evenly over a period.
- Effectively group Web Service Providers into APIs to increase the requests that can be invoked per second.
- When invoking OAuth based Web Service Providers, try to cache and reuse existing tokens rather than creating a new token for every invocation.
- Use API Logs to continuously monitor the existing traffic and regulate accordingly. Refer to Troubleshooting Using the API Logs in Working with API Logs for information about remediation needed for every HTTP Response code and optimizing the integrations accordingly to avoid errors in API invocations.
- If issues persist, contact Cleo Support.
Related Topics
- Web Service Resources
- Secure Authorization of Web Service Requests using the Server Vault.
- Troubleshooting API Errors
Comments
0 comments
Please sign in to leave a comment.