Activating the API

This API is currently available to everyone. You can activate the Google Cloud SQL API as follows:

1. Go to the Google Developers Console .
2. Select the project for which you want to activate the API.
3. In the sidebar on the left, click APIs & auth to show the list of services you can enable for your project.
4. Find the Google Cloud SQL API and ensure the Status is "ON".

Authorizing requests

Every request your application sends to the Google Cloud SQL API must include an authorization token. The token also identifies your application to Google.

About authorization protocols

We recommend using OAuth 2.0 to authorize requests.

If your application has certain unusual authorization requirements, such as logging in at the same time as requesting data access ( hybrid ) or domain-wide delegation of authority ( 2LO ), then you cannot currently use OAuth 2.0 tokens. In such cases, you must instead use OAuth 1.0 tokens and an API key . To find your application's API key:

1. Go to the Google Developers Console .
2. Select a project, or create a new one.
3. In the sidebar on the left, expand APIs & auth . Next, click APIs . In the list of APIs, make sure the status is ON for the Google Cloud SQL API.
4. In the sidebar on the left, select Credentials .
5. This API supports two types of credentials. Create whichever credentials are appropriate for your project:

   • OAuth: Your application must send an OAuth 2.0 token with any request that accesses private user data. Your application sends a client ID and, possibly, a client secret to obtain a token. You can generate OAuth 2.0 credentials for web applications, service accounts, or installed applications.

     To create an OAuth 2.0 token, click Create new Client ID , provide the required information where requested, and click Create Client ID .

     Learn more
     

     • A web application is accessed by web browsers over a network.
       • Applications that use JavaScript to access the Google Cloud SQL API must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.
       • Applications that use languages and frameworks like PHP, Java, Python, Ruby, and .NET must specify authorized redirect URIs. The redirect URIs are the endpoints to which the OAuth 2.0 server can send responses.
     • A service account is used in an application that calls APIs on behalf of an application that does not access user information. This type of application needs to prove its own identity, but it does not need a user to authorize requests. The Google Accounts documentation contains more details about service accounts.
     • An installed application runs on a desktop computer or handheld device. You can create OAuth 2.0 credentials for several types of installed applications:
       • Android : You need to specify your Android app's package name and SHA1 fingerprint.
         Show instructions

         1. In the Package name field, enter your Android app's package name .
         2. In a terminal, run the Keytool utility to get the SHA1 fingerprint for your digitally signed .apk file's public certificate.

            keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v

            The Keytool prints the fingerprint to the shell. For example:

            $ keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -list -v
            Enter keystore password: Type "android" if using debug.keystore
            Alias name: androiddebugkey
            Creation date: Aug 27, 2012
            Entry type: PrivateKeyEntry
            Certificate chain length: 1
            Certificate[1]:
            Owner: CN=Android Debug, O=Android, C=US
            Issuer: CN=Android Debug, O=Android, C=US
            Serial number: 503bd581
            Valid from: Mon Aug 27 13:16:01 PDT 2012 until: Wed Aug 20 13:16:01 PDT 2042
            Certificate fingerprints:
               MD5:  1B:2B:2D:37:E1:CE:06:8B:A0:F0:73:05:3C:A3:63:DD
               SHA1: D8:AA:43:97:59:EE:C5:95:26:6A:07:EE:1C:37:8E:F4:F0:C8:05:C8
               SHA256: F3:6F:98:51:9A:DF:C3:15:4E:48:4B:0F:91:E3:3C:6A:A0:97:DC:0A:3F:B2:D2:E1:FE:23:57:F5:EB:AC:13:30
               Signature algorithm name: SHA1withRSA
               Version: 3

            Copy the SHA1 fingerprint, which is highlighted in the example above.

         3. Paste the SHA1 fingerprint into the form where requested.
         4. Click Create Client ID .
       • Chrome application : You need to specify the Application ID for your Chrome app or extension. Use the Google Chrome Identity API to obtain that ID.
       • iOS : You need to specify the app's Bundle ID and App Store ID.
         Show instructions

         • The application's Bundle ID is the bundle identifier as listed in the app's .plist file. For example: com.example.myapp .
         • The application's App Store ID is in the app's iTunes URL so long as the app was published in the Apple iTunes App Store. For example, in the app URL http://itunes.apple.com/us/app/google+/id447119634 , the App Store ID is 447119634 .
       • Other : The Developers Console does not require any additional information to create OAuth 2.0 credentials for other types of installed applications.

   • Public API access: A request that does not provide an OAuth 2.0 token must send an API key. The key identifies your project and provides API access, quota, and reports.

     To create an API key, click Create new Key and select the appropriate key type. Enter the additional information required for that key type and click Create .

     Learn more

     • Create and use a server key if your application runs on a server. Do not use this key outside of your server code. For example, do not embed it in a web page. To prevent quota theft, restrict your key so that requests are only allowed from your servers' source IP addresses.
     • Create and use a browser key if your application runs on a client, such as a web browser. To prevent your key from being used on unauthorized sites, only allow referrals from domains you administer.
     • Create and use an iOS key if your application runs on iOS devices. Google verifies that each request originates from an iOS application that matches one of the bundle identifiers you specify. An app's .plist file contains its bundle identifier. Example: com.example.MyApp
     • Create and use an Android key if your application runs on Android devices. To do so, you need to specify the SHA1 fingerprints and package names of the application using that key.
       Show instructions

       1. In a terminal, run the Keytool utility to get the SHA1 fingerprint for your digitally signed .apk file's public certificate.

          keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v

          The Keytool prints the fingerprint to the shell. For example:

          $ keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -list -v
          Enter keystore password: Type "android" if using debug.keystore
          Alias name: androiddebugkey
          Creation date: Aug 27, 2012
          Entry type: PrivateKeyEntry
          Certificate chain length: 1
          Certificate[1]:
          Owner: CN=Android Debug, O=Android, C=US
          Issuer: CN=Android Debug, O=Android, C=US
          Serial number: 503bd581
          Valid from: Mon Aug 27 13:16:01 PDT 2012 until: Wed Aug 20 13:16:01 PDT 2042
          Certificate fingerprints:
             MD5:  1B:2B:2D:37:E1:CE:06:8B:A0:F0:73:05:3C:A3:63:DD
             SHA1: D8:AA:43:97:59:EE:C5:95:26:6A:07:EE:1C:37:8E:F4:F0:C8:05:C8
             SHA256: F3:6F:98:51:9A:DF:C3:15:4E:48:4B:0F:91:E3:3C:6A:A0:97:DC:0A:3F:B2:D2:E1:FE:23:57:F5:EB:AC:13:30
             Signature algorithm name: SHA1withRSA
             Version: 3

          Copy the SHA1 fingerprint, which is highlighted in the example above.

       2. Paste the SHA1 fingerprint into the form where requested.
       3. After the fingerprint, type a semicolon and then enter your Android app's package name .
       4. Click Create .

Authorizing requests with OAuth 2.0

All requests to the Google Cloud SQL API must be authorized by an authenticated user.

The details of the authorization process, or "flow," for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types:

1. When you create your application, you register it using the Google Developers Console . Google then provides information you'll need later, such as a client ID and a client secret.
2. Activate the Google Cloud SQL API in the Google Developers Console. (If the API isn't listed in the Developers Console, then skip this step.)
3. When your application needs access to user data, it asks Google for a particular scope of access.
4. Google displays a consent screen to the user, asking them to authorize your application to request some of their data.
5. If the user approves, then Google gives your application a short-lived access token .
6. Your application requests user data, attaching the access token to the request.
7. If Google determines that your request and the token are valid, it returns the requested data.

Some flows include additional steps, such as using refresh tokens to acquire new access tokens. For detailed information about flows for various types of applications, see Google's OAuth 2.0 documentation .

Here's the OAuth 2.0 scope information for the Google Cloud SQL API:

To request access using OAuth 2.0, your application needs the scope information, as well as information that Google supplies when you register your application (such as the client ID and the client secret).

Note : For more information on authorizing requests, see Authorize Requests .

Google Cloud SQL and Google APIs Discovery Service

Google APIs Discovery Service is a service that you can use to discover Google APIs. For example, when you use the Google APIs Explorer tool, you are using the Discovery Service. In the Discovery Service, Google Cloud SQL is represented as "sqladmin" (e.g., https://www.googleapis.com/discovery/v1/apis/ sqladmin /v1beta3/rest). This is different than the base path "sql" that you use in requests to the REST API (e.g., https://www.googleapis.com/ sql /v1beta3/projects/example-id/instances).

Some client libraries also use the Discovery Service. In the client creation code, be sure to use "sqladmin" to access the correct discovery document. For more information, see Client Libraries .

Examples

This section shows some examples of submitting requests to the Google Cloud SQL API from the command line using the Google Cloud SDK and cURL commands. After you authenticate once with the Cloud SDK ( gcloud auth login ), all subsequent authentication is handled for you. When you use the cURL command, you need to provide an authentication token for each request.

For a more complete set of examples using the Google Cloud SDK to manage your instances, see Managing Instances Using the Cloud SDK . To create Google Cloud SQL instances, you must enable billing for your project.

Request the available tiers

To test your access to the Google Cloud SQL API, try requesting information about the available tiers (such as D1, D2 and so on). You need an access token to request the list of tiers, but you do not need any project-specific information.

The following example sends a request to list the available tiers.

$ gcloud sql tiers list

curl --header 'Authorization: Bearer accessToken' \
     --header 'Content-Type: application/json' \
     https://www.googleapis.com/sql/v1beta3/projects/your-project-id/tiers

Get the Google Cloud SQL instances in a project

The following example sends a request to list the Google Cloud SQL instances in the project whose ID is your-project-id .

$ gcloud config set project your-project-id
$ gcloud sql instances list

curl --header 'Authorization: Bearer accessToken' \
     --header 'Content-Type: application/json' \
     https://www.googleapis.com/sql/v1beta3/projects/your-project-id/instances

Get information about a Google Cloud SQL instance

The following example sends a request to get information about the your-instance-name instance in your-project-id project.

$ gcloud sql instances get your-project-id:your-instance-name

curl --header 'Authorization: Bearer accessToken' \
     --header 'Content-Type: application/json' \
     https://www.googleapis.com/sql/v1beta3/projects/your-project-id/instances/your-instance-name

Create a Google Cloud SQL instance

The following command sends a request to insert (create) a new Google Cloud SQL D2 instance named your-instance-name in the your-project-id project. You can get information about the newly created instance and check when the instance state to see if the instance is ready to use.

$ gcloud config set project your-project-id
$ gcloud sql instances create your-instance-name --tier D2

curl --header 'Authorization: Bearer accessToken' \
     --header 'Content-Type: application/json' \
     https://www.googleapis.com/sql/v1beta3/projects/your-project-id/instances \
     --data '{"instance" : "your-instance-name", "project" : "your-project-id", "settings" : {"tier" : "D2"}}' -X POST

Import a database from a MySQL dump file on Google Cloud Storage into a Google Cloud SQL instance

The following commands send a request to import a SQL dump file into the your-instance-name instance in the your-project-id project.

$ gcloud config set project your-project-id
$ gcloud sql instances import your-instance-name --uri gs://yourbucket/sqldumptoimport.gz

curl --header 'Authorization: Bearer accessToken' \
     --header 'Content-Type: application/json' \
     https://www.googleapis.com/sql/v1beta3/projects/your-project-id/instances/your-instance-name/import  \
    --data '{"importContext" : { "kind": "sql#importContext","uri": ["gs://yourbucket/sqldumptoimport"]}}' -X POST