Mock sample for your project: AWS Audit Manager API

The Amazon API Gateway Management API allows you to directly manage runtime aspects of your deployed APIs. To use it, you must explicitly set the SDK's endpoint to point to the endpoint of your deployed API. The endpoint will be of the form https://{api-id}.execute-api.{region}.amazonaws.com/{stage}, or will be the endpoint corresponding to your API's custom domain and base path, if applicable.

Key Management Service Key Management Service (KMS) is an encryption and key management web service. This guide describes the KMS operations that you can call programmatically. For general information about KMS, see the Key Management Service Developer Guide . KMS is replacing the term customer master key (CMK) with KMS key and KMS key. The concept has not changed. To prevent breaking changes, KMS is keeping some variations of this term. Amazon Web Services provides SDKs that consist of libraries and sample code for various programming languages and platforms (Java, Ruby, .Net, macOS, Android, etc.). The SDKs provide a convenient way to create programmatic access to KMS and other Amazon Web Services services. For example, the SDKs take care of tasks such as signing requests (see below), managing errors, and retrying requests automatically. For more information about the Amazon Web Services SDKs, including how to download and install them, see Tools for Amazon Web Services. We recommend that you use the Amazon Web Services SDKs to make programmatic API calls to KMS. Clients must support TLS (Transport Layer Security) 1.0. We recommend TLS 1.2. Clients must also support cipher suites with Perfect Forward Secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes. Signing Requests Requests must be signed by using an access key ID and a secret access key. We strongly recommend that you do not use your Amazon Web Services account (root) access key ID and secret key for everyday work with KMS. Instead, use the access key ID and secret access key for an IAM user. You can also use the Amazon Web Services Security Token Service to generate temporary security credentials that you can use to sign requests. All KMS operations require Signature Version 4. Logging API Requests KMS supports CloudTrail, a service that logs Amazon Web Services API calls and related events for your Amazon Web Services account and delivers them to an Amazon S3 bucket that you specify. By using the information collected by CloudTrail, you can determine what requests were made to KMS, who made the request, when it was made, and so on. To learn more about CloudTrail, including how to turn it on and find your log files, see the CloudTrail User Guide. Additional Resources For more information about credentials and request signing, see the following: Amazon Web Services Security Credentials - This topic provides general information about the types of credentials used to access Amazon Web Services. Temporary Security Credentials - This section of the IAM User Guide describes how to create and use temporary security credentials. Signature Version 4 Signing Process - This set of topics walks you through the process of signing a request using an access key ID and a secret access key. Commonly Used API Operations Of the API operations discussed in this guide, the following will prove the most useful for most applications. You will likely perform operations other than these, such as creating keys and assigning policies, by using the console. Encrypt Decrypt GenerateDataKey GenerateDataKeyWithoutPlaintext

Amazon CloudWatch monitors your Amazon Web Services (Amazon Web Services) resources and the applications you run on Amazon Web Services in real time. You can use CloudWatch to collect and track metrics, which are the variables you want to measure for your resources and applications. CloudWatch alarms send notifications or automatically change the resources you are monitoring based on rules that you define. For example, you can monitor the CPU usage and disk reads and writes of your Amazon EC2 instances. Then, use this data to determine whether you should launch additional instances to handle increased load. You can also use this data to stop under-used instances to save money. In addition to monitoring the built-in metrics that come with Amazon Web Services, you can monitor your own custom metrics. With CloudWatch, you gain system-wide visibility into resource utilization, application performance, and operational health.

The AWS Migration Hub home region APIs are available specifically for working with your Migration Hub home region. You can use these APIs to determine a home region, as well as to create and work with controls that describe the home region. You must make API calls for write actions (create, notify, associate, disassociate, import, or put) while in your home region, or a HomeRegionNotSetException error is returned. API calls for read actions (list, describe, stop, and delete) are permitted outside of your home region. If you call a write API outside the home region, an InvalidInputException is returned. You can call GetHomeRegion action to obtain the account's Migration Hub home region. For specific API usage, see the sections that follow in this AWS Migration Hub Home Region API reference.

The FinSpace APIs let you take actions inside the FinSpace environment.

Glue Defines the public endpoint for the Glue service.

Amazon SES API v2 Welcome to the Amazon SES API v2 Reference. This guide provides information about the Amazon SES API v2, including supported operations, data types, parameters, and schemas. Amazon SES is an AWS service that you can use to send email messages to your customers. If you're new to Amazon SES API v2, you might find it helpful to also review the Amazon Simple Email Service Developer Guide. The Amazon SES Developer Guide provides information and code samples that demonstrate how to use Amazon SES API v2 features programmatically. The Amazon SES API v2 is available in several AWS Regions and it provides an endpoint for each of these Regions. For a list of all the Regions and endpoints where the API is currently available, see AWS Service Endpoints in the Amazon Web Services General Reference. To learn more about AWS Regions, see Managing AWS Regions in the Amazon Web Services General Reference. In each Region, AWS maintains multiple Availability Zones. These Availability Zones are physically isolated from each other, but are united by private, low-latency, high-throughput, and highly redundant network connections. These Availability Zones enable us to provide very high levels of availability and redundancy, while also minimizing latency. To learn more about the number of Availability Zones that are available in each Region, see AWS Global Infrastructure.

Introduction The Amazon Interactive Video Service (IVS) API is REST compatible, using a standard HTTP API and an AWS EventBridge event stream for responses. JSON is used for both requests and responses, including errors. The API is an AWS regional service, currently in these regions: us-west-2, us-east-1, and eu-west-1. All API request parameters and URLs are case sensitive. For a summary of notable documentation changes in each release, see Document History. Service Endpoints The following are the Amazon IVS service endpoints (all HTTPS): Region name: US West (Oregon) Region: us-west-2 Endpoint: ivs.us-west-2.amazonaws.com Region name: US East (Virginia) Region: us-east-1 Endpoint: ivs.us-east-1.amazonaws.com Region name: EU West (Dublin) Region: eu-west-1 Endpoint: ivs.eu-west-1.amazonaws.com Allowed Header Values Accept: application/json Accept-Encoding: gzip, deflate Content-Type: application/json Resources The following resources contain information about your IVS live stream (see Getting Started with Amazon IVS): Channel — Stores configuration data related to your live stream. You first create a channel and then use the channel’s stream key to start your live stream. See the Channel endpoints for more information. Stream key — An identifier assigned by Amazon IVS when you create a channel, which is then used to authorize streaming. See the StreamKey endpoints for more information. Treat the stream key like a secret, since it allows anyone to stream to the channel. Playback key pair — Video playback may be restricted using playback-authorization tokens, which use public-key encryption. A playback key pair is the public-private pair of keys used to sign and validate the playback-authorization token. See the PlaybackKeyPair endpoints for more information. Recording configuration — Stores configuration related to recording a live stream and where to store the recorded content. Multiple channels can reference the same recording configuration. See the Recording Configuration endpoints for more information. Tagging A tag is a metadata label that you assign to an AWS resource. A tag comprises a key and a value, both set by you. For example, you might set a tag as topic:nature to label a particular video category. See Tagging AWS Resources for more information, including restrictions that apply to tags. Tags can help you identify and organize your AWS resources. For example, you can use the same tag for different resources to indicate that they are related. You can also use tags to manage access (see Access Tags). The Amazon IVS API has these tag-related endpoints: TagResource, UntagResource, and ListTagsForResource. The following resources support tagging: Channels, Stream Keys, Playback Key Pairs, and Recording Configurations. Authentication versus Authorization Note the differences between these concepts: Authentication is about verifying identity. You need to be authenticated to sign Amazon IVS API requests. Authorization is about granting permissions. You need to be authorized to view Amazon IVS private channels. (Private channels are channels that are enabled for "playback authorization.") Authentication All Amazon IVS API requests must be authenticated with a signature. The AWS Command-Line Interface (CLI) and Amazon IVS Player SDKs take care of signing the underlying API calls for you. However, if your application calls the Amazon IVS API directly, it’s your responsibility to sign the requests. You generate a signature using valid AWS credentials that have permission to perform the requested action. For example, you must sign PutMetadata requests with a signature generated from an IAM user account that has the ivs:PutMetadata permission. For more information: Authentication and generating signatures — See Authenticating Requests (AWS Signature Version 4) in the AWS General Reference. Managing Amazon IVS permissions — See Identity and Access Management on the Security page of the Amazon IVS User Guide. Channel Endpoints CreateChannel — Creates a new channel and an associated stream key to start streaming. GetChannel — Gets the channel configuration for the specified channel ARN (Amazon Resource Name). BatchGetChannel — Performs GetChannel on multiple ARNs simultaneously. ListChannels — Gets summary information about all channels in your account, in the AWS region where the API request is processed. This list can be filtered to match a specified name or recording-configuration ARN. Filters are mutually exclusive and cannot be used together. If you try to use both filters, you will get an error (409 Conflict Exception). UpdateChannel — Updates a channel's configuration. This does not affect an ongoing stream of this channel. You must stop and restart the stream for the changes to take effect. DeleteChannel — Deletes the specified channel. StreamKey Endpoints CreateStreamKey — Creates a stream key, used to initiate a stream, for the specified channel ARN. GetStreamKey — Gets stream key information for the specified ARN. BatchGetStreamKey — Performs GetStreamKey on multiple ARNs simultaneously. ListStreamKeys — Gets summary information about stream keys for the specified channel. DeleteStreamKey — Deletes the stream key for the specified ARN, so it can no longer be used to stream. Stream Endpoints GetStream — Gets information about the active (live) stream on a specified channel. ListStreams — Gets summary information about live streams in your account, in the AWS region where the API request is processed. StopStream — Disconnects the incoming RTMPS stream for the specified channel. Can be used in conjunction with DeleteStreamKey to prevent further streaming to a channel. PutMetadata — Inserts metadata into the active stream of the specified channel. A maximum of 5 requests per second per channel is allowed, each with a maximum 1 KB payload. (If 5 TPS is not sufficient for your needs, we recommend batching your data into a single PutMetadata call.) PlaybackKeyPair Endpoints For more information, see Setting Up Private Channels in the Amazon IVS User Guide. ImportPlaybackKeyPair — Imports the public portion of a new key pair and returns its arn and fingerprint. The privateKey can then be used to generate viewer authorization tokens, to grant viewers access to private channels (channels enabled for playback authorization). GetPlaybackKeyPair — Gets a specified playback authorization key pair and returns the arn and fingerprint. The privateKey held by the caller can be used to generate viewer authorization tokens, to grant viewers access to private channels. ListPlaybackKeyPairs — Gets summary information about playback key pairs. DeletePlaybackKeyPair — Deletes a specified authorization key pair. This invalidates future viewer tokens generated using the key pair’s privateKey. RecordingConfiguration Endpoints CreateRecordingConfiguration — Creates a new recording configuration, used to enable recording to Amazon S3. GetRecordingConfiguration — Gets the recording-configuration metadata for the specified ARN. ListRecordingConfigurations — Gets summary information about all recording configurations in your account, in the AWS region where the API request is processed. DeleteRecordingConfiguration — Deletes the recording configuration for the specified ARN. AWS Tags Endpoints TagResource — Adds or updates tags for the AWS resource with the specified ARN. UntagResource — Removes tags from the resource with the specified ARN. ListTagsForResource — Gets information about AWS tags for the specified ARN.

Amplify enables developers to develop and deploy cloud-powered mobile and web apps. The Amplify Console provides a continuous delivery and hosting service for web applications. For more information, see the Amplify Console User Guide. The Amplify Framework is a comprehensive set of SDKs, libraries, tools, and documentation for client app development. For more information, see the Amplify Framework.

Amazon Simple Notification Service Amazon Simple Notification Service (Amazon SNS) is a web service that enables you to build distributed web-enabled applications. Applications can use Amazon SNS to easily push real-time notification messages to interested subscribers over multiple delivery protocols. For more information about this product see the Amazon SNS product page. For detailed information about Amazon SNS features and their associated API calls, see the Amazon SNS Developer Guide. For information on the permissions you need to use this API, see Identity and access management in Amazon SNS in the Amazon SNS Developer Guide. We also provide SDKs that enable you to access Amazon SNS from your preferred programming language. The SDKs contain functionality that automatically takes care of tasks such as: cryptographically signing your service requests, retrying requests, and handling error responses. For a list of available SDKs, go to Tools for Amazon Web Services.

Amazon CloudWatch Application Insights Amazon CloudWatch Application Insights is a service that helps you detect common problems with your applications. It enables you to pinpoint the source of issues in your applications (built with technologies such as Microsoft IIS, .NET, and Microsoft SQL Server), by providing key insights into detected problems. After you onboard your application, CloudWatch Application Insights identifies, recommends, and sets up metrics and logs. It continuously analyzes and correlates your metrics and logs for unusual behavior to surface actionable problems with your application. For example, if your application is slow and unresponsive and leading to HTTP 500 errors in your Application Load Balancer (ALB), Application Insights informs you that a memory pressure problem with your SQL Server database is occurring. It bases this analysis on impactful metrics and log errors.

Welcome to the Amazon AppFlow API reference. This guide is for developers who need detailed information about the Amazon AppFlow API operations, data types, and errors. Amazon AppFlow is a fully managed integration service that enables you to securely transfer data between software as a service (SaaS) applications like Salesforce, Marketo, Slack, and ServiceNow, and Amazon Web Services like Amazon S3 and Amazon Redshift. Use the following links to get started on the Amazon AppFlow API: Actions : An alphabetical list of all Amazon AppFlow API operations. Data types : An alphabetical list of all Amazon AppFlow data types. Common parameters : Parameters that all Query operations can use. Common errors : Client and server errors that all operations can return. If you're new to Amazon AppFlow, we recommend that you review the Amazon AppFlow User Guide. Amazon AppFlow API users can use vendor-specific mechanisms for OAuth, and include applicable OAuth attributes (such as auth-code and redirecturi) with the connector-specific ConnectorProfileProperties when creating a new connector profile using Amazon AppFlow API operations. For example, Salesforce users can refer to the Authorize Apps with OAuth documentation.

The Azure SQL Database management API provides a RESTful set of web APIs that interact with Azure SQL Database services to manage your databases. The API enables users to create, retrieve, update, and delete databases, servers, and other entities.

API spec for Microsoft.Security (Azure Security Center) resource provider

The APIs listed in this specification can be used to manage Deployment Scripts resource through the Azure Resource Manager.

The Microsoft Azure Network management API provides a RESTful set of web services that interact with Microsoft Azure Networks service to manage your network resources. The API has entities that capture the relationship between an end user and the Microsoft Azure Networks service.

REST APIs for orchestrating deployments using the Azure Deployment Manager (ADM). See https://docs.microsoft.com/en-us/azure/azure-resource-manager/deployment-manager-overview for more information.

Introduction
The Linode API provides the ability to programmatically manage the full
range of Linode products and services.
This reference is designed to assist application developers and system
administrators. Each endpoint includes descriptions, request syntax, and
examples using standard HTTP requests. Response data is returned in JSON
format.
This document was generated from our OpenAPI Specification. See the
OpenAPI website for more information.
Download the Linode OpenAPI Specification.
Changelog
View our Changelog to see release
notes on all changes made to our API.
Access and Authentication
Some endpoints are publicly accessible without requiring authentication.
All endpoints affecting your Account, however, require either a Personal
Access Token or OAuth authentication (when using third-party
applications).
Personal Access Token
The easiest way to access the API is with a Personal Access Token (PAT)
generated from the
Linode Cloud Manager or
the Create Personal Access Token endpoint.
All scopes for the OAuth security model (defined below) apply to this
security model as well.
Authentication
| Security Scheme Type: | HTTP |
|-----------------------|------|
| HTTP Authorization Scheme | bearer |
OAuth
If you only need to access the Linode API for personal use,
we recommend that you create a personal access token.
If you're designing an application that can authenticate with an arbitrary Linode user, then
you should use the OAuth 2.0 workflows presented in this section.
For a more detailed example of an OAuth 2.0 implementation, see our guide on How to Create an OAuth App with the Linode Python API Library.
Before you implement OAuth in your application, you first need to create an OAuth client. You can do this with the Linode API or via the Cloud Manager:
When creating the client, you'll supply a label and a redirect_uri (referred to as the Callback URL in the Cloud Manager).
The response from this endpoint will give you a client_id and a secret.
Clients can be public or private, and are private by default. You can choose to make the client public when it is created.
A private client is used with applications which can securely store the client secret (that is, the secret returned to you when you first created the client). For example, an application running on a secured server that only the developer has access to would use a private OAuth client. This is also called a confidential client in some OAuth documentation.
A public client is used with applications where the client secret is not guaranteed to be secure. For example, a native app running on a user's computer may not be able to keep the client secret safe, as a user could potentially inspect the source of the application. So, native apps or apps that run in a user's browser should use a public client.
Public and private clients follow different workflows, as described below.
OAuth Workflow
The OAuth workflow is a series of exchanges between your third-party app and Linode. The workflow is used
to authenticate a user before an application can start making API calls on the user's behalf.
Notes:
With respect to the diagram in section 1.2 of RFC 6749, login.linode.com (referred to in this section as the login server)
is the Resource Owner and the Authorization Server; api.linode.com (referred to here as the api server) is the Resource Server.
The OAuth spec refers to the private and public workflows listed below as the authorization code flow and implicit flow.
| PRIVATE WORKFLOW | PUBLIC WORKFLOW |
|------------------|------------------|
| 1. The user visits the application's website and is directed to login with Linode. | 1. The user visits the application's website and is directed to login with Linode. |
| 2. Your application then redirects the user to Linode's login server with the client application's clientid and requested OAuth scope, which should appear in the URL of the login page. | 2. Your application then redirects the user to Linode's login server with the client application's clientid and requested OAuth scope, which should appear in the URL of the login page. |
| 3. The user logs into the login server with their username and password. | 3. The user logs into the login server with their username and password. |
| 4. The login server redirects the user to the specificed redirect URL with a temporary authorization code (exchange code) in the URL. | 4. The login server redirects the user back to your application with an OAuth accesstoken embedded in the redirect URL's hash. This is temporary and expires in two hours. No refreshtoken is issued. Therefore, once the access_token expires, a new one will need to be issued by having the user log in again. |
| 5. The application issues a POST request (see below) to the login server with the exchange code, clientid, and the client application's clientsecret. | |
| 6. The login server responds to the client application with a new OAuth accesstoken and refreshtoken. The access_token is set to expire in two hours. | |
| 7. The refreshtoken can be used by contacting the login server with the clientid, clientsecret, granttype, and refreshtoken to get a new OAuth accesstoken and refreshtoken. The new accesstoken is good for another two hours, and the new refresh_token, can be used to extend the session again by this same method. | |
OAuth Private Workflow - Additional Details
The following information expands on steps 5 through 7 of the private workflow:
Once the user has logged into Linode and you have received an exchange code,
you will need to trade that exchange code for an accesstoken and refreshtoken. You
do this by making an HTTP POST request to the following address:
Rate Limiting
With the Linode API, you can make up to 1,600 general API requests every two minutes per user as
determined by IP adddress or by OAuth token. Additionally, there are endpoint specfic limits defined below.
Note: There may be rate limiting applied at other levels outside of the API, for example, at the load balancer.
/stats endpoints have their own dedicated limits of 100 requests per minute per user.
These endpoints are:
View Linode Statistics
View Linode Statistics (year/month)
View NodeBalancer Statistics
List Managed Stats
Object Storage endpoints have a dedicated limit of 750 requests per second per user.
The Object Storage endpoints are:
Object Storage Endpoints
Opening Support Tickets has a dedicated limit of 2 requests per minute per user.
That endpoint is:
Open Support Ticket
Accepting Service Transfers has a dedicated limit of 2 requests per minute per user.
That endpoint is:
Service Transfer Accept
CLI (Command Line Interface)
The Linode CLI allows you to easily
work with the API using intuitive and simple syntax. It requires a
Personal Access Token
for authentication, and gives you access to all of the features and functionality
of the Linode API that are documented here with CLI examples.
Endpoints that do not have CLI examples are currently unavailable through the CLI, but
can be accessed via other methods such as Shell commands and other third-party applications.

HyperDrive REST API

Cognitive Services Management Client

Azure Digital Twins Client for managing DigitalTwinsInstance

The Anomaly Finder API detects anomalies automatically in time series data. It supports two functionalities, one is for detecting the whole series with model trained by the timeseries, another is detecting last point with model trained by points before. By using this service, business customers can discover incidents and establish a logic flow for root cause analysis.