Currently the only way to provide credentials is either via jenkins system configuration or to hardcode those inside the job configuration (which is a security concern as it exposes sensitive information at the job level). Ideally the credentials should be stored elsewhere.

P.S. Having sensitive API keys/tokens and other credentials that are managed from a central place makes it easier to switch those in one place instead of having to change every job configuration.

From Credentials plugin wiki page:
----------------
Information for Plugin Developers

_The credentials plugin provides two main extension points:

Credentials - a base class for all Credentials types managed by the credentials plugin. Most plugin authors will just want to subclass this type to define what they need to store in the credential type... better yet, if you can find an existing Credentials subclass that stores your credentials. So, for example, if somebody created a ssh-credentials plugin that just defines a SshCredentials class, then anyone needing ssh credentials could just depend on that... [Note that careful use of readResolve can allow this to be introduced after the fact]
CredentialsProvider - an extension point for something that can provide credentials. For example, the CloudBees Folders plugin uses this extension point to provide folder scoped credentials, so that the credentials are only available to jobs within the folder.

When you need to get back some credentials you just call CredentialsProvider.lookupCredentials(type,item,auth,domainRequirements) to retrieve the appropriate credentials.
The type parameter is the class of credentials you want to retrieve.
The item parameter is the job you want to retrieve the credentials for, but this could also be the Jenkins instance itself; e.g., if getting the email credentials when Jenkins is sending emails, if getting the ssh credentials for Jenkins to start a slave node with, etc.
The auth parameter is the authentication that is requesting the credentials. In general this will be ACL.SYSTEM but, for example, the version 2.0 of the CloudBees Deployer plugin adds a “Deploy Now” action which allows a user to use their own user-scoped credentials to deploy an already built web application to their own RUN servlet container instance (useful for testing older builds to see if you have a valid test case for that bug).
The domainRequirements parameter is the list of requirements against which domain specifications will be verified when retrieving credentials._