REST API
Seldon Enterprise Platform API
The REST API of Seldon Enterprise Platform lets you interact with your machine learning deployments programmatically. This allows you to build complex deployment pipelines to integrate Seldon Enterprise Platform with any upstream services.

If you already have access to a Seldon Enterprise Platform installation, you can visit the interactive API reference to learn more about the Seldon Enterprise Platform API and the endpoints that it exposes. The interactive API documentation can be accessed by clicking on your profile icon, and then clicking on API Docs. Alternatively, you can go directly to $ML_PLATFORM_HOST/seldon-deploy/swagger/, where $ML_PLATFORM_HOST needs to be replaced by the domain where your Seldon Enterprise Platform installation can be accessed.
Usage
The recommended way of interacting with the Seldon Enterprise Platform REST API is through its Python SDK. However, you can also use plain cURL to send requests.
You can find some example usages below.
We can use cURL (available on most distributions) or similar HTTP clients to interact directly with the Seldon Enterprise Platform API.
For example, if we assume that there is an authentication token present in the $TOKEN variable, we could list our machine learning deployments as:
To use the Python SDK, the first step will be to install the seldon-deploy-sdk package. You can do so using pip as:
Once we have obtained an authentication token, we will need to set it as the id_token of our Configuration object. Afterwards, we could list all our machine learning deployments under the staging namespace as:
Authentication
All requests to the Seldon Enterprise Platform API must be authenticated. Therefore, before using the API you must obtain an authentication token. Note that the process to issue a new authentication token may change depending on your architecture and your OIDC provider.
Out of the box, the Python SDK supports a set of common authentication workflows. Each of these can be found under the seldon_deploy_sdk.auth package.
OIDCAuthenticator: Allows you to authenticate against an OIDC-compatible provider, using theauth_code,client_credentials, andpasswordflows.
Authorization code
Multi-phase process suitable for human users of SDKs
auth_code
Client ID
Client secret
Client credentials
Single-phase process suitable for automated clients in trusted environments
client_credentials
Client ID
Client secret
Password grant
Single-phase process suitable for human users of SDKs in trusted environments
password_grant
Username
User password
Client ID
(Optional) client secret
SessionAuthenticator: Allows you to authenticate against Dex, configured as an ingress-level authentication provider.
You can see some authentication examples below. Further details can be found in the Python SDK reference documentation .
CA Certificates The following examples assume the use of HTTPS. If you are using self-signed certificates, e.g. with a trial installation of Seldon Enterprise Platform, and have not configured these on your local machine, you can still follow the examples by disabling certificate verification.
To disable certificate verification with cURL, use the -k option.
To disable certificate verification with the Python SDK, set the verify_ssl attribute on your Configuration object to False:
Auth Code Flow
This is the recommended OIDC flow as it is the most secure for client applications like the Python SDK. It is suitable for interactive workflows where a human user is involved.
It is a multi-stage process:
Users log in to their OIDC provider directly through a browser
After successfully logging in, the user is redirected to the service they want to access, i.e. Seldon Enterprise Platform
The user is shown a one-time access code
The user's client exchanges this code for a long-lived token which can be used for subsequent requests
The code-token exchange can optionally use client credentials for an added layer of security.

For this example, we will assume that the authorization-code flow is supported and that the OIDC client is confidential.
In Keycloak, this can be done by setting Standard Flow Enabled, ensuring the client's Access Type is confidential, and checking the Valid Redirect URIs list includes /seldon-deploy/auth/callback through the client dashboard in the admin UI.
We can use plain cURL to obtain a token, by emulating OpenID's authorization code flow.
Assuming you have jq installed, use the following to generate a URL which you can copy into your browser:
This URL will take you to a Keycloak page where you can log in.
After logging in, you will be redirected to a Seldon Enterprise Platform page displaying an authorization code. You can exchange the one-time code for a long-lived token as shown below:
The Python SDK supports the authorization-code flow with auth_code as the authentication method.
To generate an authorization request URL:
You will be presented with instructions and an authorization URL. Click or copy and paste the URL into your browser, where you can log in to Keycloak.
After logging in, you will be redirected to a Seldon Enterprise Platform page displaying an authorization code. You can exchange the one-time code for a long-lived token by entering the code into the Python prompt. Save the token for later use with:
Client Credentials Flow
This should only be used in trusted environments as there is no user authentication involved. It may be suitable for automated pipelines such as for CI workflows.
This is a simple request-response flow:
The client sends a request to its OIDC provider with its client ID and a secret known only to it and the identity provider
The OIDC provider responds with a long-lived token that can be used for future requests

For this example, we will assume that the client credentials flow is supported and that the OIDC client is confidential.
In Keycloak, this can be done by setting Service Accounts Enabled and ensuring the client's Access Type is confidential through the client dashboard in the admin UI.
We can use plain cURL to obtain a token, by emulating OpenID's client credentials flow.
The Python SDK supports the client-credentials flow with client_credentials as the authentication method.
Password Grant Flow
This flow is generally not recommended as it requires a user's credentials to be exposed to a client application. Users may be tempted to store their username and password in an unencrypted file for convenience, and these credentials are at risk of being leaked through logging or because they are held unencrypted in the client.
This is a simple request-response flow:
The user provides their username and password to the client
The client sends a request to the OIDC provider with the user's credentials
The OIDC provider responds with a long-lived token that can be used for future requests
The request can optionally use client credentials for an added layer of security.

For this example, we will assume that the password grant flow is supported and that the OIDC client is confidential.
In Keycloak, this can be done by setting Direct Access Grants Enabled and ensuring the client's Access Type is confidential through the client dashboard in the admin UI.
We can use plain cURL to obtain a token, by emulating OpenID's password flow.
If we assume a set up where Keycloak is configured as an OIDC provider and that there is an OpenID client named sd-api, we could obtain an authorization token to access the API using plain cURL as:
The Python SDK supports the password-grant flow with password_grant as the authentication method.
Session Authentication
This approach does not require explicitly configuring an endpoint for the authentication provider. Requests to Seldon Enterprise Platform are intercepted at the ingress to the cluster and authenticated using cookies.
This is a simple request-response flow:
The user provides their username and password to the client
The client sends a request to Seldon Enterprise Platform which is intercepted and redirected to the auth provider
The client sends a request to this auth provider with the user's credentials
The auth provider responds with a long-lived cookie that can be used for future requests
For this example, we will assume the use of Dex as the identity provider. This is the auth mechanism for kubeflow.
Versioning
The API endpoints are versioned to avoid clashes between different versions of the API. The current version of the API is v1alpha1, which means that breaking changes are still highly likely to happen. Once the current version graduates to stable, it will be renamed to v1.
Note that this versioning schema is similar to the one followed in Kubernetes.
API Reference (v1alpha1)
Last updated
Was this helpful?


