Test and publish Services

The environment configuration and permissions set at the project level control who can publish a Service:
  • With publishing enabled for all users, anyone with read, write, and execute permissions on a Service's project can publish it.
  • With publishing disabled, only environment admins can publish. Refer to Configure DeveloperHub settings for information on how to configure publishing settings.

Test or publish a Service to DeveloperHub by changing its status. Before publishing, you can set up subscriptions.

Service statuses

Click the status pill next to the Service name to open the status menu. The initial status on creation or migration is Unpublished. The following statuses are available:


Service statuses

The status determines whether a Service is visible in the DeveloperHub and whether endpoints are usable:

  • Unpublished: Not available in DeveloperHub and not functional. The Service must meet minimal requirements before you can move it to another status.
  • Testing: Not available in DeveloperHub. The Service and all endpoints meet minimal requirements, are functional, and ready to test with the URL and path.
  • Private: Not available in DeveloperHub. Endpoints are functional and can be used by calling the URL.
  • Restricted: Available in DeveloperHub to users with a SnapLogic login who have access to the underlying Service.
  • Public: Available in DeveloperHub to all users — those who have a SnapLogic or a DeveloperHub login, assuming the portal is configured to require login.
Important: You can't modify a Service in any published status, private, restricted, or public. You must unpublish it first.

You can't change the Service to a published status until validation passes with no errors. Refer to Validation for more information.

Testing endpoints

You can test an endpoint with a command line tool like cURL or an app like Postman. Copy the URL from the clipboard in the path row:

Paste the URL in the test environment. Add any required parameters and authentication.

Subscriptions

Subscriptions give consumers access to Services for a specified timeframe. Subscription settings can apply to the current Service or all versions of the Service. The settings include an expiration timeframe, the type of key (JWT or API), and whether requests get approved automatically.

Configure and manage subscriptions describes how to set up and approve or reject subscription requests.

Enable consumers to try out endpoints

Consumers can exercise endpoints from DeveloperHub without leaving the site when Services have the appropriate CORS and one or more supported authentication rules. The supported authentication rules include API Key Authenticator rule, Basic Auth rule, Callout Authenticator rule, and JWT Validator rule.

To enable the Try it out feature:

  1. Create a policy with a CORS Restriction rule and one or more of the supported authentication rules.
  2. Apply the policy to the Service or endpoint.
  3. Publish the Service to DeveloperHub with Public visibility.
When a consumer clicks the endpoint details, Authorize and Try it out buttons display:
Endpoint with try it out enabled

Refer to Enable Try it out for an example.

Publishing Services created by migration

APIM 3.0 allows you to migrate existing API versions and Proxies to Services without breaking existing client integrations. After migration, when you publish the new Service, APIM 3.0 automatically routes incoming requests for the original API or Proxy endpoint to the migrated Service’s endpoints.

For Service versions created by migration:

  • When published, both the Service URL and the original API or Proxy URLs execute the new Service.
  • If published and then unpublished, the original API or Proxy URLs execute (as long as they weren't removed) but the new endpoints don't execute.
  • If published and moved to testing, the original API or Proxy URLs execute (as long as they weren't removed) and the new Service endpoints execute.

We recommend directing new clients to use the published Service version endpoints going forward.

Deprecate a Service or Service version

If you plan to end-of-life a version of a Service, enable the Deprecated toggle in the Service or Service version edit dialog. This informs those using the Service that they should plan to migrate to a different version. You can provide details in the Documentation for the Service, such as the cut-off date.

The following describe how to perform tasks related to Services and endpoints: