Java SDK - Developer

Walk through step-by-step in our intro to custom integration course (30 mins). Obtain the SDK The SDK is available on Maven Central, ready to be included in your project: Include the latest version of the Java SDK in your project as a dependency. You can also give a specific version instead of the + , if you'd like. The Java SDK uses slf4j for logging purposes. You can include logback as a simple binding mechanism to send any logging information out to your console (standard out), at INFO -level or above. Configure the SDK There are two ways to configure the SDK: Using environment variables ATLAN_API_KEY should be given your Atlan API token , for authentication ( don't forget to assign one or more personas to the API token to give access to existing assets! ) ATLAN_BASE_URL should be given your Atlan URL (for example, https://tenant.atlan.com ) Here's an example of setting those environment variables: On client creation If you prefer to not use environment variables, you can do the following: Careful not to expose your API token! We generally discourage including your API token directly in your code, in case you accidentally commit it into a (public) version control system. But it's your choice exactly how you manage the API token and including it for use within the client. (Note that you can also explicity provide only the tenant URL, and the constructor will look for only the API key through an environment variable.) That's it — once these are set you can start using your SDK to make live calls against your Atlan instance! 🎉 Delve into more detailed examples: Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events The SDK defines checked exceptions for the following categories of error: A given API call could fail due to all of the errors above. So these all extend a generic AtlanException checked exception, and all API operations throw AtlanException . For example, when creating a connection there is an asynchronous process that grants permissions to the admins of that connection. So there can be a slight delay between creating the connection and being permitted to do any operations with the connection. During that delay, any attempt to interact with the connection will result in a PermissionException , even if your API token was used to create connection in the first place. Another example you may occasionally hit is some network issue that causes your connection to Atlan to be interrupted. In these cases, an ApiConnectionException will be raised. Don't worry, the SDK retries automatically While these are useful to know for detecting issues, the SDK automatically retries on such problems. Atlan is a distributed, cloud-native application, where network problems can arise. These advanced configuration options allow you to optimize how the SDK handles such ephemeral problems. The SDK uses slf4j to be logging framework-agnostic. You can therefore configure your own preferred logging framework: Replace the ch.qos.logback:logback-classic:1.2.11 logback binding with log4j2 bindings. The SDK handles automatically retrying your requests when it detects certain problems: When an ApiConnectionException occurs that is caused by an underlying ConnectException or SocketTimeoutException . When there is a 403 response indicating that permission for an operation is not (yet) available. When there is a 500 response indicating that something went wrong on the server side. If any request encounters one of these problems, it will be retried. Before each retry, the SDK will apply a delay using: An exponential backoff (starting from 500ms) A jitter (in the range of 75-100% of the backoff delay) Each retry will be at least 500ms, and at most 5s. (Currently these values are not configurable.) For each request that encounters any of these problems, only up to a maximum number of retries will be attempted. (This is set to 3 by default.) You can configure the maximum number of retries globally using setMaxNetworkRetries() on a client. Set this to an integer: The SDK will only wait so long for a response before assuming a network problem has occurred and the request should be timed out. By default, this is set to 80 seconds. You can configure the maximum time the SDK will wait before timing out a request using setReadTimeout() on a client. Set this to an integer giving the number of milliseconds before timing out: Remember this must be given in milliseconds. This example sets the timeout to 2 minutes (120 seconds * 1000 milliseconds). Since version 0.9.0, the Java SDK supports connecting to multiple tenants. From version 4.0.0 onwards you can create any number of clients against any number of different tenants, since every operation that interacts with a tenant now explicitly requires a client to be provided to it: Constructing a new client with a different tenant's URL is sufficient to create connectivity to that other tenant. You can also (optionally) provide a second argument to directly give the API token for the tenant. Create an object as usual. You can access the operations for assets directly on the client, under client.assets . These will generally give you the most flexibility — they can handle multiple objects at a time and allow overrides. Every operation on the client itself has a variant with an (optional) final argument through which you can override settings like retry limits or timeouts for this single request. You can use the from(client) factory method to initialize the request options with all the settings of your client, and then you only need to chain on those you want to override for this particular request. Alternatively, you can pass the client to the operation on the object itself. Limit the number of clients to those you must have Each client you create maintains its own independent copy of various caches. So the more clients you have, the more resources your code will consume. For this reason, we recommended limiting the number of clients you create to the bare minimum you require — ideally just a single client per tenant. Using a proxy To use the Java SDK with a proxy, you need to send in some additional parameters when running any java . command. These are described in detail in the Java documentation , but are summarized here for simplicity: socksProxyHost should be set to the hostname for your SOCKS proxy socksProxyPort should be set to the port for your SOCKS proxy (default being 1080) Providing credentials to the proxy In either case, if you need to authenticate to your proxy, you will need to wrap whatever code you want to run to set up these credentials using something like the following: You need to create a built-in Java PasswordAuthentication object. Provide your username as the first argument. . and your password as the second argument, as a char[] . (Of course, you should not hard-code your password in your code itself, but rather pull it from elsewhere.) Then use setProxyCredential() to pass this PasswordAuthentication object to the Atlan client, before any of the rest of the code will execute.


Python SDK - Developer

Walk through step-by-step in our intro to custom integration course (30 mins). Obtain the SDK The SDK is currently available on pypi . You can use pip to install it as follows: Configure the SDK There are two ways to configure the SDK: Using environment variables ATLAN_API_KEY should be given your Atlan API token , for authentication ( don't forget to assign one or more personas to the API token to give access to existing assets! ) ATLAN_BASE_URL should be given your Atlan URL (for example, https://tenant.atlan.com ) Here's an example of setting those environment variables: On client creation If you prefer to not use environment variables, you can do the following: Careful not to expose your API token! We generally discourage including your API token directly in your code, in case you accidentally commit it into a (public) version control system. But it's your choice exactly how you manage the API token and including it for use within the client. In some scenarios, you may not want to expose the entire API token or manage environment variables. Instead, you can provide the GUID of the API token, and the SDK will internally fetch the actual access token. When to use this approach: Building apps that use the SDK where token security is a concern When you want to avoid exposing full API tokens in your configuration For containerized applications that need secure token management Before using this approach, ensure your Argo template is configured with CLIENT_ID and CLIENT_SECRET : Create client from token GUID : Use AtlanClient.from_token_guid() to create a client using the GUID of an API token. The SDK will automatically fetch the actual access token using the configured CLIENT_ID and CLIENT_SECRET . That's it — once these are set you can start using your SDK to make live calls against your Atlan instance! 🎉 Delve into more detailed examples: Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events The SDK defines exceptions for the following categories of error: A given API call could fail due to all of the errors above. So these all extend a generic AtlanError exception, and all API operations can potentially raise AtlanError . For example, when creating a connection there is an asynchronous process that grants permissions to the admins of that connection. So there can be a slight delay between creating the connection and being permitted to do any operations with the connection. During that delay, any attempt to interact with the connection will result in a PermissionError , even if your API token was used to create connection in the first place. Another example you may occasionally hit is some network issue that causes your connection to Atlan to be interrupted. In these cases, an ApiConnectionError will be raised. Don't worry, the SDK retries automatically While these are useful to know for detecting issues, the SDK automatically retries on such problems. Atlan is a distributed, cloud-native application, where network problems can arise. The SDK therefore automatically attempts to handle ephemeral problems. The SDK uses logging module of the standard library that can provide a flexible framework for emitting log messages. You can enable logging for your SDK script by adding the following lines above your snippets: You can enable logging by using basicConfig with various logging levels: logging.DEBUG : used to give detailed information, typically of interest only when diagnosing problems (mostly used level in SDK). logging.INFO : used to confirm that things are working as expected. logging.WARN : used as an indication that something unexpected happened, or as a warning of some problem in the near future. logging.ERROR : indicates that due to a more serious problem, the SDK has not been able to perform some operation. logging.CRITICAL : indicates a serious error, suggesting that the program itself may be unable to continue running (not used in SDK as of now). You can enable logging by using basicConfig with various logging levels: logging.DEBUG : used to give detailed information, typically of interest only when diagnosing problems (mostly used level in SDK). logging.INFO : used to confirm that things are working as expected. logging.WARN : used as an indication that something unexpected happened, or as a warning of some problem in the near future. logging.ERROR : indicates that due to a more serious problem, the SDK has not been able to perform some operation. logging.CRITICAL : indicates a serious error, suggesting that the program itself may be unable to continue running (not used in SDK as of now). By default, logs will appear in your console. If you want to use file logging, you can add the following line: logging.config.fileConfig('pyatlan/logging.conf') : this will generate logs according to the configuration defined in pyatlan/logging.conf and will generate two log files: /tmp/pyatlan.log : default log file. /tmp/pyatlan.json : log file in JSON format. By default, logs will appear in your console. If you want to use file logging, you can add the following line: logging.config.fileConfig('pyatlan/logging.conf') : this will generate logs according to the configuration defined in pyatlan/logging.conf and will generate two log files: /tmp/pyatlan.log : default log file. /tmp/pyatlan.json : log file in JSON format. logging.config.fileConfig('pyatlan/logging.conf') : this will generate logs according to the configuration defined in pyatlan/logging.conf and will generate two log files: /tmp/pyatlan.log : default log file. /tmp/pyatlan.json : log file in JSON format. The SDK handles automatically retrying your requests when it detects certain problems: When there is a 403 response indicating that permission for an operation is not (yet) available. When there is a 429 response indicating that the request rate limit has been exceeded, and you need to retry after some time. When there is a 50x response indicating that something went wrong on the server side. If any request encounters one of these problems, it will be retried. Before each retry, the SDK will apply a delay using an exponential backoff. (Currently the values for the exponential backoff are not configurable.) For each request that encounters any of these problems, only up to a maximum number of retries will be attempted. (This is set to 5 by default.) By default, the SDK AtlanClient() has the following timeout settings: read_timeout : 900.0 seconds ( 15 minutes) connect_timeout : 30.0 seconds If you need to override these defaults, you can do so as shown in the example below: Since version 1.0.0, the Python SDK supports connecting to multiple tenants.[^1] When you use the AtlanClient() method you are actually setting a default client. This default client will be used behind-the-scenes for any operations that need information specific to an Atlan tenant. When you want to override that default client you can create a new one and use the set_default_client() method to change it: The AtlanClient() method will return a client for the given base URL, creating a new client and setting this new client as the default client. If you want to switch between clients that you have already created, you can use Atlan.set_default_client() to change between them. Limit the number of clients to those you must have Each client you create maintains its own independent copy of various caches. So the more clients you have, the more resources your code will consume. For this reason, we recommended limiting the number of clients you create to the bare minimum you require — ideally just a single client per tenant. (And since in the majority of use cases you only need access to a single tenant, this means you can most likely just rely on the default client and the fallback behavior.) Pyatlan uses the Requests library which supports proxy configuration via environment variables. Requests relies on the proxy configuration defined by standard environment variables http_proxy, https_proxy, no_proxy, and all_proxy. Uppercase variants of these variables are also supported. You can therefore set them to configure Pyatlan (only set the ones relevant to your needs): To use HTTP Basic Auth with your proxy, use the http://user:password@host/ syntax in any of the above configuration entries: Currently, the way this is implemented limits you to either avoiding multiple threads in your Python code (if you need to use multiple clients), or if you want to use multiple threads you should only use a single client. Asynchronous SDK operations To get started, you need to initialize an AsyncAtlanClient : Create an async client using the same configuration pattern as the synchronous client. Concurrent operations for improved performance The real power of async comes from running multiple operations concurrently . Instead of waiting for each operation to complete sequentially, you can execute them in parallel and reduce total execution time: Synchronous : Total time = operation₁ + operation₂ + . + operationₙ Asynchronous : Total time = max(operation₁, operation₂, . , operationₙ) When to use async Async is most beneficial when you have: Multiple independent operations that can run concurrently I/O-heavy workloads like API calls, database queries, or file operations Long-running operations where parallelization provides significant time savings For simple, single operations, the synchronous client may be more straightforward to use.


Kotlin SDK - Developer

Obtain the SDK For Kotlin, you can reuse the existing Java SDK as-is. It is available on Maven Central, ready to be included in your project: Include the latest version of the Java SDK in your project as a dependency. You can also give a specific version instead of the + , if you'd like. The Java SDK uses slf4j for logging purposes. You can include slf4j-simple as a simple binding mechanism to send any logging information out to your console (standard out), along with the kotlin-logging-jvm microutil. Configure the SDK There are two ways to configure the SDK: Using environment variables ATLAN_API_KEY should be given your Atlan API token , for authentication ( don't forget to assign one or more personas to the API token to give access to existing assets! ) ATLAN_BASE_URL should be given your Atlan URL (for example, https://tenant.atlan.com ) Here's an example of setting those environment variables: On client creation If you prefer to not use environment variables, you can do the following: Delve into more detailed examples: Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events The SDK defines checked exceptions for the following categories of error: A given API call could fail due to all of the errors above. So these all extend a generic AtlanException checked exception, and all API operations throw AtlanException . For example, when creating a connection there is an asynchronous process that grants permissions to the admins of that connection. So there can be a slight delay between creating the connection and being permitted to do any operations with the connection. During that delay, any attempt to interact with the connection will result in a PermissionException , even if your API token was used to create connection in the first place. Another example you may occasionally hit is some network issue that causes your connection to Atlan to be interrupted. In these cases, an ApiConnectionException will be raised. Don't worry, the SDK retries automatically While these are useful to know for detecting issues, the SDK automatically retries on such problems. Atlan is a distributed, cloud-native application, where network problems can arise. These advanced configuration options allow you to optimize how the SDK handles such ephemeral problems. The SDK uses slf4j to be logging framework-agnostic. You can therefore configure your own preferred logging framework: Replace the org.slf4j:slf4j-simple:2.0.7 binding with log4j2 bindings. The SDK handles automatically retrying your requests when it detects certain problems: When an ApiConnectionException occurs that is caused by an underlying ConnectException or SocketTimeoutException . When there is a 403 response indicating that permission for an operation is not (yet) available. When there is a 500 response indicating that something went wrong on the server side. If any request encounters one of these problems, it will be retried. Before each retry, the SDK will apply a delay using: An exponential backoff (starting from 500ms) A jitter (in the range of 75-100% of the backoff delay) Each retry will be at least 500ms, and at most 5s. (Currently these values are not configurable.) For each request that encounters any of these problems, only up to a maximum number of retries will be attempted. (This is set to 3 by default.) You can configure the maximum number of retries globally using setMaxNetworkRetries() on a client. Set this to an integer: The SDK will only wait so long for a response before assuming a network problem has occurred and the request should be timed out. By default, this is set to 80 seconds. You can configure the maximum time the SDK will wait before timing out a request using setReadTimeout() on a client. Set this to an integer giving the number of milliseconds before timing out: Remember this must be given in milliseconds. This example sets the timeout to 2 minutes (120 seconds * 1000 milliseconds). Since version 0.9.0, the Java SDK supports connecting to multiple tenants. From version 4.0.0 onwards you can create any number of clients against any number of different tenants, since every operation that interacts with a tenant now explicitly requires a client to be provided to it: Constructing a new client with a different tenant's URL is sufficient to create connectivity to that other tenant. You can also (optionally) provide a second argument to directly give the API token for the tenant. Create an object as usual. You can access the operations for assets directly on the client, under client.assets . These will generally give you the most flexibility — they can handle multiple objects at a time and allow overrides. Every operation on the client itself has a variant with an (optional) final argument through which you can override settings like retry limits or timeouts for this single request. You can use the from(client) factory method to initialize the request options with all the settings of your client, and then you only need to chain on those you want to override for this particular request. Alternatively, you can pass the client to the operation on the object itself. Limit the number of clients to those you must have Each client you create maintains its own independent copy of various caches. So the more clients you have, the more resources your code will consume. For this reason, we recommended limiting the number of clients you create to the bare minimum you require — ideally just a single client per tenant. Using a proxy To use the Java SDK with a proxy, you need to send in some additional parameters when running any java . command. These are described in detail in the Java documentation , but are summarized here for simplicity: socksProxyHost should be set to the hostname for your SOCKS proxy socksProxyPort should be set to the port for your SOCKS proxy (default being 1080) Providing credentials to the proxy In either case, if you need to authenticate to your proxy, you will need to wrap whatever code you want to run to set up these credentials using something like the following: You need to create a built-in Java PasswordAuthentication object. Provide your username as the first argument. . and your password as the second argument, as a char[] . (Of course, you should not hard-code your password in your code itself, but rather pull it from elsewhere.) Then use setProxyCredential() to pass this PasswordAuthentication object to the Atlan client, before any of the rest of the code will execute.


Scala SDK - Developer

Obtain the SDK For Scala, you can reuse the existing Java SDK as-is. It is available on Maven Central, ready to be included in your project: Include the latest version of the Java SDK in your project as a dependency (replace the version number with the latest version indicated in the badges above). The Java SDK uses slf4j for logging purposes. You can include the scala-logging utility as a simple binding mechanism to send any logging information out to your console (standard out). Configure the SDK There are two ways to configure the SDK: Using environment variables ATLAN_API_KEY should be given your Atlan API token , for authentication ( don't forget to assign one or more personas to the API token to give access to existing assets! ) ATLAN_BASE_URL should be given your Atlan URL (for example, https://tenant.atlan.com ) Here's an example of setting those environment variables: On client creation If you prefer to not use environment variables, you can do the following: Delve into more detailed examples: Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events The SDK defines checked exceptions for the following categories of error: A given API call could fail due to all of the errors above. So these all extend a generic AtlanException checked exception, and all API operations throw AtlanException . For example, when creating a connection there is an asynchronous process that grants permissions to the admins of that connection. So there can be a slight delay between creating the connection and being permitted to do any operations with the connection. During that delay, any attempt to interact with the connection will result in a PermissionException , even if your API token was used to create connection in the first place. Another example you may occasionally hit is some network issue that causes your connection to Atlan to be interrupted. In these cases, an ApiConnectionException will be raised. Don't worry, the SDK retries automatically While these are useful to know for detecting issues, the SDK automatically retries on such problems. Atlan is a distributed, cloud-native application, where network problems can arise. These advanced configuration options allow you to optimize how the SDK handles such ephemeral problems. The SDK uses slf4j to be logging framework-agnostic. You can therefore configure your own preferred logging framework: Add log4j2 bindings. The SDK handles automatically retrying your requests when it detects certain problems: When an ApiConnectionException occurs that is caused by an underlying ConnectException or SocketTimeoutException . When there is a 403 response indicating that permission for an operation is not (yet) available. When there is a 500 response indicating that something went wrong on the server side. If any request encounters one of these problems, it will be retried. Before each retry, the SDK will apply a delay using: An exponential backoff (starting from 500ms) A jitter (in the range of 75-100% of the backoff delay) Each retry will be at least 500ms, and at most 5s. (Currently these values are not configurable.) For each request that encounters any of these problems, only up to a maximum number of retries will be attempted. (This is set to 3 by default.) You can configure the maximum number of retries globally using setMaxNetworkRetries() on a client. Set this to an integer: The SDK will only wait so long for a response before assuming a network problem has occurred and the request should be timed out. By default, this is set to 80 seconds. You can configure the maximum time the SDK will wait before timing out a request using setReadTimeout() on a client. Set this to an integer giving the number of milliseconds before timing out: Remember this must be given in milliseconds. This example sets the timeout to 2 minutes (120 seconds * 1000 milliseconds). Since version 0.9.0, the Java SDK supports connecting to multiple tenants. From version 4.0.0 onwards you can create any number of clients against any number of different tenants, since every operation that interacts with a tenant now explicitly requires a client to be provided to it: Constructing a new client with a different tenant's URL is sufficient to create connectivity to that other tenant. You can also (optionally) provide a second argument to directly give the API token for the tenant. Create an object as usual. You can access the operations for assets directly on the client, under client.assets . These will generally give you the most flexibility — they can handle multiple objects at a time and allow overrides. Every operation on the client itself has a variant with an (optional) final argument through which you can override settings like retry limits or timeouts for this single request. You can use the from(client) factory method to initialize the request options with all the settings of your client, and then you only need to chain on those you want to override for this particular request. Alternatively, you can pass the client to the operation on the object itself. Limit the number of clients to those you must have Each client you create maintains its own independent copy of various caches. So the more clients you have, the more resources your code will consume. For this reason, we recommended limiting the number of clients you create to the bare minimum you require — ideally just a single client per tenant. Using a proxy To use the Java SDK with a proxy, you need to send in some additional parameters when running any java . command. These are described in detail in the Java documentation , but are summarized here for simplicity: socksProxyHost should be set to the hostname for your SOCKS proxy socksProxyPort should be set to the port for your SOCKS proxy (default being 1080) Providing credentials to the proxy In either case, if you need to authenticate to your proxy, you will need to wrap whatever code you want to run to set up these credentials using something like the following: You need to create a built-in Java PasswordAuthentication object. Provide your username as the first argument. . and your password as the second argument, as a char[] . (Of course, you should not hard-code your password in your code itself, but rather pull it from elsewhere.) Then use setProxyCredential() to pass this PasswordAuthentication object to the Atlan client, before any of the rest of the code will execute.


Clojure SDK - Developer

Obtain the SDK For Clojure, you can reuse the existing Java SDK as-is. It is available on Maven Central, ready to be included in your project: Include the latest version of the Java SDK in your project as a dependency (replace the version number with the latest version indicated in the badges above). The Java SDK uses slf4j for logging purposes. You can include the org.clojure/tools.logging utility as a simple binding mechanism to send any logging information out to your console (standard out). Configure the SDK There are two ways to configure the SDK: Using environment variables ATLAN_API_KEY should be given your Atlan API token , for authentication ( don't forget to assign one or more personas to the API token to give access to existing assets! ) ATLAN_BASE_URL should be given your Atlan URL (for example, https://tenant.atlan.com ) Here's an example of setting those environment variables: On client creation If you prefer to not use environment variables, you can do the following: Delve into more detailed examples: Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events The SDK defines checked exceptions for the following categories of error: A given API call could fail due to all of the errors above. So these all extend a generic AtlanException checked exception, and all API operations throw AtlanException . For example, when creating a connection there is an asynchronous process that grants permissions to the admins of that connection. So there can be a slight delay between creating the connection and being permitted to do any operations with the connection. During that delay, any attempt to interact with the connection will result in a PermissionException , even if your API token was used to create connection in the first place. Another example you may occasionally hit is some network issue that causes your connection to Atlan to be interrupted. In these cases, an ApiConnectionException will be raised. Don't worry, the SDK retries automatically While these are useful to know for detecting issues, the SDK automatically retries on such problems. Atlan is a distributed, cloud-native application, where network problems can arise. These advanced configuration options allow you to optimize how the SDK handles such ephemeral problems. The SDK uses slf4j to be logging framework-agnostic. You can therefore configure your own preferred logging framework: Add log4j2 bindings. The SDK handles automatically retrying your requests when it detects certain problems: When an ApiConnectionException occurs that is caused by an underlying ConnectException or SocketTimeoutException . When there is a 403 response indicating that permission for an operation is not (yet) available. When there is a 500 response indicating that something went wrong on the server side. If any request encounters one of these problems, it will be retried. Before each retry, the SDK will apply a delay using: An exponential backoff (starting from 500ms) A jitter (in the range of 75-100% of the backoff delay) Each retry will be at least 500ms, and at most 5s. (Currently these values are not configurable.) For each request that encounters any of these problems, only up to a maximum number of retries will be attempted. (This is set to 3 by default.) You can configure the maximum number of retries globally using setMaxNetworkRetries() on a client. Set this to an integer: The SDK will only wait so long for a response before assuming a network problem has occurred and the request should be timed out. By default, this is set to 80 seconds. You can configure the maximum time the SDK will wait before timing out a request using setReadTimeout() on a client. Set this to an integer giving the number of milliseconds before timing out: Remember this must be given in milliseconds. This example sets the timeout to 2 minutes (120 seconds * 1000 milliseconds). Since version 0.9.0, the Java SDK supports connecting to multiple tenants. From version 4.0.0 onwards you can create any number of clients against any number of different tenants, since every operation that interacts with a tenant now explicitly requires a client to be provided to it: Constructing a new client with a different tenant's URL is sufficient to create connectivity to that other tenant. You can also (optionally) provide a second argument to directly give the API token for the tenant. Create an object as usual. You can access the operations for assets directly on the client, under client.assets . These will generally give you the most flexibility — they can handle multiple objects at a time and allow overrides. Every operation on the client itself has a variant with an (optional) final argument through which you can override settings like retry limits or timeouts for this single request. You can use the from(client) factory method to initialize the request options with all the settings of your client, and then you only need to chain on those you want to override for this particular request. Alternatively, you can pass the client to the operation on the object itself. Limit the number of clients to those you must have Each client you create maintains its own independent copy of various caches. So the more clients you have, the more resources your code will consume. For this reason, we recommended limiting the number of clients you create to the bare minimum you require — ideally just a single client per tenant. Using a proxy To use the Java SDK with a proxy, you need to send in some additional parameters when running any java . command. These are described in detail in the Java documentation , but are summarized here for simplicity: socksProxyHost should be set to the hostname for your SOCKS proxy socksProxyPort should be set to the port for your SOCKS proxy (default being 1080) Providing credentials to the proxy In either case, if you need to authenticate to your proxy, you will need to wrap whatever code you want to run to set up these credentials using something like the following: You need to create a built-in Java PasswordAuthentication object. Provide your username as the first argument. . and your password as the second argument, as a char[] . (Of course, you should not hard-code your password in your code itself, but rather pull it from elsewhere.) You need to create a built-in Java PasswordAuthentication object. Provide your username as the first argument. . and your password as the second argument, as a char[] . (Of course, you should not hard-code your password in your code itself, but rather pull it from elsewhere.) Then use setProxyCredential() to pass this PasswordAuthentication object to the Atlan client, before any of the rest of the code will execute. Then use setProxyCredential() to pass this PasswordAuthentication object to the Atlan client, before any of the rest of the code will execute.


Go SDK - Developer

Obtain the SDK The Go SDK is currently in a pre-release, experimental state. While in this state, we reserve the right to make any changes to it (including breaking changes) without worrying about backwards compatibility, semantic versioning, and so on. If you are eager to experiment with it, it is available on GitHub . You can use Go dependencies to install it directly from there. We welcome your feedback during the pre-release, but cannot commit to any specific revisions or timelines at this point in time. Configure the SDK There are two ways to configure the SDK: Using environment variables ATLAN_API_KEY should be given your Atlan API token , for authentication ( don't forget to assign one or more personas to the API token to give access to existing assets! ) ATLAN_BASE_URL should be given your Atlan URL (for example, https://tenant.atlan.com ) Here's an example of setting those environment variables: On client creation If you prefer to not use environment variables, you can do the following: Careful not to expose your API token! We generally discourage including your API token directly in your code, in case you accidentally commit it into a (public) version control system. But it's your choice exactly how you manage the API token and including it for use within the client. That's it — once these are set you can start using your SDK to make live calls against your Atlan instance! 🎉 Delve into more detailed examples: Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events The SDK defines exceptions for the following categories of error: A given API call could fail due to all of the errors above. So these all extend a generic AtlanError exception, and all API operations can potentially raise AtlanError . For example, when creating a connection there is an asynchronous process that grants permissions to the admins of that connection. So there can be a slight delay between creating the connection and being permitted to do any operations with the connection. During that delay, any attempt to interact with the connection will result in a PermissionError , even if your API token was used to create connection in the first place. Another example you may occasionally hit is some network issue that causes your connection to Atlan to be interrupted. In these cases, an ApiConnectionError will be raised. Atlan is a distributed, cloud-native application, where network problems can arise. The SDK therefore automatically attempts to handle ephemeral problems. The SDK uses the slog library internally to provide a flexible framework for emitting log messages. You can enable logging for your SDK script by adding the following lines above your snippets: You can enable logging by using .SetLogger() on the context object with various logging levels: "debug" : used to give detailed information, typically of interest only when diagnosing problems (mostly used level in SDK). "info" : used to confirm that things are working as expected. "warn" : used as an indication that something unexpected happened, or as a warning of some problem in the near future. "error" : indicates that due to a more serious problem, the SDK has not been able to perform some operation. You can enable logging by using .SetLogger() on the context object with various logging levels: "debug" : used to give detailed information, typically of interest only when diagnosing problems (mostly used level in SDK). "info" : used to confirm that things are working as expected. "warn" : used as an indication that something unexpected happened, or as a warning of some problem in the near future. "error" : indicates that due to a more serious problem, the SDK has not been able to perform some operation.


Events - Developer

Atlan produces events when certain activities occur in the system. You can tap into these in a push-based integration model to take action the moment they occur. To tap into the events, you need to first set up a webhook in Atlan. Have a look at the event handling pattern for more details on implementing event-handling from webhooks using either of the SDKs.


Raw REST API - Developer

Raw REST API Walk through step-by-step in our intro to custom integration course (30 mins). There are a number of details and nuances to understand about the underlying REST APIs to use them most effectively: the underlying REST API communications (HTTP protocols, methods, headers, endpoint URLs, response codes, etc) translating the complex JSON structures for each request and response payload knowing exactly which values are required (and which aren't) depending on the object you're interacting with, what operation you're carrying out, etc (including which exact string (and capitalization) to use for values that are really enumerations behind-the-scenes) Ultimately, all pull-based integration mechanisms (including the SDKs) use the REST API; however, the SDKs also encode best practices to avoid the need to understand all these details and low-level nuances. If you want to adopt these best practices from the start, we would strongly recommend directly using any of our SDKs rather than the raw REST APIs directly: That being said, we have documented the raw REST API interactions in most cases. So if you really want to interact with the APIs directly, there should still be some guidance — anywhere you see Raw REST API gives details on endpoint URLs, methods, and payloads. If all you really want to do is some initial experimentation directly against the API, you can use Postman . We do not maintain a Postman collection of requests, but you can use the Raw REST API tab to find the endpoint and an example payload to use for most operations here on developer.atlan.com. Why not just publish an OpenAPI spec? We did try this in the past, as we liked the idea of generating client libraries using tools like the OpenAPI Generator . Unfortunately, in our own testing of these tools, we found that: We could generate code that is free from syntax errors, but the generated code was not fully functional. Problems we found: The generated code drops significant portions of data from payloads. (Our APIs are payload-rich and endpoint-light, while the generators seem to favor endpoint-rich and payload-light APIs.) The various objects the generator creates often make developer consumption cumbersome — long, difficult-to-read object names; many variations of similar objects; and so on. The generated code naturally does not include any validation that can't be encoded in the OpenAPI spec. To add this we'd need to wrap the generated code with another layer anyway. After several attempts at mangling the OpenAPI spec to meet the constraints of the code generator, we eventually decided to go the way we've seen other API-first companies adopt. We found very few API-first companies appear to rely on these code generators, but rather directly maintain their own SDKs for which they may have their own code generators. (Which is in fact exactly what we're doing as well.) Request for feedback If you use the raw REST APIs rather than one of the provided SDKs, we would love to understand more. If you can spare a few minutes to fill out our survey , we would be very grateful!


Customer support | Atlan Documentation

One of Atlan's core values is to help you and your team do your life's best work. ð That's why Atlan wants to make it as easy as possible for you to keep driving your work forward with data. Atlan's customer support is a combination of several teams in Atlan: Product support personnel Cloud support personnel DevOps/engineering support personnel Vast repository of self-service resources Service-level commitment Atlan's Technical Support team provides support globally with high response commitment levels. This includes 24/7 SRE support for critical (P0) issues. Customers get a service-level commitment, including the following: 99.5% uptime for Atlan Dedicated support center, available from within the Atlan product Commitments for aggressive response times for business critical issues Designated Customer Success Manager to assist with escalations Ways to contact support ï¸ Email support at a dedicated customer support email account ( [email protected] ) ð ¨ ð » In-product support widget to log tickets and a help desk portal to log and track tickets. You can sign up to track support tickets on the help desk portal. You must use your organizational email address as the username and create a password. ð Submit a support request via the online form. To track your support tickets: Navigate to https://atlan.zendesk.com and log into the help desk portal with your credentials or via SSO. From the top right, click your avatar, and then from the dropdown, click My activities . On the My activities page, you can do the following: My requests and Requests I'm CC'd on - view and edit the support tickets you either created or were copied on, respectively. Organization requests - to access all other support tickets for your organization, please reach out to your customer success manager. Atlan provides you with read access to all the support tickets for your organization. To be able to comment on or close them, you must be CC'd on all tickets. My requests and Requests I'm CC'd on - view and edit the support tickets you either created or were copied on, respectively. Organization requests - to access all other support tickets for your organization, please reach out to your customer success manager. Atlan provides you with read access to all the support tickets for your organization. To be able to comment on or close them, you must be CC'd on all tickets. Hours of operation 24x7 availability for all requests and issues Severity levels The Atlan Technical Support team determines the severity of an issue. The customer's position is considered, and these guidelines are followed to determine priority. Below are the response time SLAs: Escalation procedure If the business impact of a support request changes or a ticket isn't being handled according to your expectations, you may escalate the ticket. Please first speak with the Technical Support representative assigned to the ticket to confirm that the business impact and urgency are understood. You may further escalate by contacting: 1st level of escalation : Technical Support Engineer 2nd level of escalation : Director, Support 3rd level of escalation : Head of Customer Experience Ways to contact support Hours of operation


Customer support | Atlan Documentation


Email Protection | Cloudflare

You are unable to access this email address atlan.com The website from which you got to this page is protected by Cloudflare. Email addresses on that page have been hidden in order to keep them from being accessed by malicious bots. You must enable Javascript in your browser in order to decode the e-mail address . If you have a website and are interested in protecting it in a similar way, you can sign up for Cloudflare . How does Cloudflare protect email addresses on website from spammers? Can I sign up for Cloudflare? Cloudflare Ray ID: 97e29b39d988990a • Your IP: Click to reveal 130.91.58.216 • Performance & security by Cloudflare


Developing with Atlan - Developer

Overall site map If you are new to Atlan, or to developing with Atlan, start with one of the following two options. These will set you up to develop with Atlan, step-by-step. Atlan University Self-paced, video-based walkthrough of the essentials of Atlan as a platform. Atlan Platform Essentials certification Self-paced, video-based walkthrough of the essentials of Atlan as a platform. Atlan Platform Essentials certification Introductory walkthrough Documentation-based walkthrough, including step-by-step examples. Start the walkthrough Documentation-based walkthrough, including step-by-step examples. Start the walkthrough Common tasks Common operations on assets, that are available across all assets. Discover actions Common operations on assets, that are available across all assets. Asset-specific Operations that are specific to certain assets. Focus on a specific kind of asset Operations that are specific to certain assets. Focus on a specific kind of asset Governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Operations dealing with governance structures, rather than assets. Manage governance structures Samples Real code samples our customers use to solve particular use cases. Review live samples Real code samples our customers use to solve particular use cases. Review live samples Events Delve deep into the details of the events Atlan triggers. Learn more about events Delve deep into the details of the events Atlan triggers. Learn more about events


Developing with Atlan - Developer