Ana içeriğe geç

Import Keystore File

Endpoint​

POST /apiops/projects/{projectName}/keystores/import-file/
bilgi

This uploads the raw file. To restore a keystore from an Apinizer package produced by Export Keystore, use Import Keystore instead.

Authentication​

Requires a Personal API Access Token.

Authorization: Bearer YOUR_TOKEN

Request​

Headers​

HeaderValueRequired
AuthorizationBearer {token}Yes
Content-Typemultipart/form-dataYes

Path Parameters​

ParameterTypeRequiredDescription
projectNamestringYesProject name

Form Fields​

FieldTypeRequiredDefaultDescription
keystoreFilefileYes—The keystore file (.jks, .p12 or .pfx), or the ZIP produced by Export Keystore File
keystoreNamestringYes—Name of the keystore to create or update
passwordstringYes—Keystore password
environmentListstringConditional—Comma-separated environment names. Required for a single file; ignored for a ZIP, whose environments come from its entries
environmentMappingstring (JSON)No—Maps an environment name in the archive to one on this installation, for example {"UAT": "Production"}. An empty value marks that environment as deliberately not transferred. Only meaningful for a ZIP
keyStoreTypestringNoinferredJKS or PKCS12. When omitted, it is inferred from the file extension
keystoreDescriptionstringNo—Description
aliasstringNo—Alias stored with the material
overridebooleanNofalseWhen true, updates an existing keystore of that name; otherwise a new one is created

Response​

Success Response (200 OK)​

{
  "status": "SUCCESS"
}

When the keystore was stored but could not be deployed to its environments, the response says so:

{
  "status": "SUCCESS",
  "resultMessage": "Keystore was saved successfully but deployment to environments failed. Details: ...",
  "deploymentResult": {
    "success": false,
    "detailList": []
  }
}

When part of the upload could not be carried over, the response says so:

{
  "status": "SUCCESS",
  "unresolvedReferences": [
    "Environment (Staging) was deliberately left out by the caller's mapping.",
    "Archive entry (README.txt) does not name an environment of keystore (my-keystore) and was not imported."
  ]
}

Error Response (400 Bad Request)​

{
  "status": "FAILURE",
  "resultMessage": "Keystore (name: partner-store) is already exist! Send override=true to update it."
}

or

{
  "status": "FAILURE",
  "resultMessage": "Unknown keyStoreType (BCFKS)! Supported values: JKS, PKCS12"
}

or

{
  "status": "FAILURE",
  "resultMessage": "password value can not be empty!"
}

or

{
  "status": "FAILURE",
  "resultMessage": "Environment (Staging) is not found or user does not have privilege to access it!"
}

Common Causes​

  • A keystore of that name already exists and override was not set
  • override=true was sent but no keystore of that name exists
  • keyStoreType is neither JKS nor PKCS12
  • password or environmentList is empty, or an environment cannot be reached by the user

Error Response (401 Unauthorized)​

{
  "status": "FAILURE",
  "resultMessage": "Token is not valid!"
}

cURL Example​

Example 1: Upload a PKCS12 Keystore​

curl -X POST \
  "https://demo.apinizer.com/apiops/projects/MyProject/keystores/import-file/" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -F "keystoreFile=@partner-store.p12" \
  -F "keystoreName=partner-store" \
  -F "password=YOUR_PASSWORD" \
  -F "environmentList=Production,UAT"

Example 2: Upload a JKS Keystore with an Explicit Type​

curl -X POST \
  "https://demo.apinizer.com/apiops/projects/MyProject/keystores/import-file/" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -F "keystoreFile=@partner-store.keystore" \
  -F "keystoreName=partner-store" \
  -F "password=YOUR_PASSWORD" \
  -F "keyStoreType=JKS" \
  -F "environmentList=Production"

Example 3: Rotate an Existing Keystore​

curl -X POST \
  "https://demo.apinizer.com/apiops/projects/MyProject/keystores/import-file/" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -F "keystoreFile=@partner-store-2027.pfx" \
  -F "keystoreName=partner-store" \
  -F "password=YOUR_PASSWORD" \
  -F "environmentList=Production" \
  -F "override=true"

Example: Restore a Multi-Environment Keystore from its Export​

curl -X POST \
  "https://demo.apinizer.com/apiops/projects/MyProject/keystores/import-file/" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -F "keystoreFile=@my-keystore-keystores.zip" \
  -F "keystoreName=my-keystore" \
  -F "override=true"

Notes and Warnings​

  • The type is inferred from the extension: .p12 and .pfx are read as PKCS12, anything else as JKS. An explicit keyStoreType always wins, which is what an unconventional extension needs.
  • A ZIP restores each environment from its own entry: entries are matched by the <keystoreName>-<environmentName>.p12 naming the export writes. Anything else in the archive is reported in unresolvedReferences rather than guessed at — writing material into the wrong environment is silent and permanent.
  • Environments are merged, never wiped: an environment this upload does not name keeps the material it already had. Per-environment material normally differs, so an import that replaced the whole list would make a multi-environment object impossible to restore. To remove an environment deliberately, use the update endpoint with the list you want to keep.
  • One file, every named environment: the uploaded file is written to each environment in environmentList. To give environments different keystores, call the endpoint once per environment, or upload the export archive.
  • An empty environment list is rejected: a keystore written to no environment reaches nothing, while the call would still read success. A ZIP upload does not need one — its entries carry the environments.
  • The file name is remembered: its extension is reused when the keystore is downloaded again through Export Keystore File.
  • The bytes are stored as uploaded: the file that comes back out is the file that went in.

Permissions​

  • User must have SECRETS + EXPORT_IMPORT permission in the project
En son tarihinde güncellendi