Skip to main content
Grupo

OpenAPI Specs for Salesforce REST APIs

Forum to share feedback, ask questions, provide suggestions, request features/enhancements, etc. regarding the representation of Salesforce's REST APIs with an OpenAPI Specification document (see https://ideas.salesforce.com/s/idea/a0B8W00000GdcNPUAZ/ability-to-generate-openapi-docs-for-restful-integration).

Hi everyone! 

I'm trying to use the "Generating an OpenAPI 3.0" trough workbench but it is always giving me the following error:

Generating an OpenAPI 3.0 not working with Workbench

Can anyone help me on this? 

Is this something feasable? 

 

 

Thank you! 

Mattia

8 respostas
  1. Eric Burté (DEVOTEAM) Forum Ambassador
    Ontem 21:54

    Hello @Rey Rojas that is a beta feature. As mentioned in the related documentation (https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/openapi_beta.htm),  the API version in the GET (and also the POST) request must be the latest version. See screenshots below for example :Hello that is a beta feature. As mentioned in the related documentation (), the API version in the GET (and also the POST) request must be the latest version.Andimage.pngEric 

0/9000

I ran this in my simple org and came up with a spec that's close to 700K lines.   I need to be able to give out a simple spec focusing on just specific objects.  700K is too big to even filter without a lot of work.      

13 respostas
  1. 14 de jan. de 2025, 00:03

    In Spring '25 release we have re-worked the OAS generated for sObjects API to use a parameterized OAS to reduce the size of the generated spec.  Spring '25 is currently deployed to sandboxes so you can get the new OAS there.

0/9000

Hello everyone, 

 

We’re currently working on generating an OpenAPI 3.0 specification from Salesforce.

The generation works as expected, but when we try to import the resulting spec into a downstream platform, we receive the following error: 

 

Import failed 

Please adjust your OpenAPI specification and try again.

Reason: Invalid Request Body

  • Schema cannot contain any allOf, oneOf, or $ref
  • Must have required property "$ref"
  • Must not have additional properties
  • Must match exactly one schema in oneOf, etc.

 

The problem appears to stem from Salesforce's use of allOf, oneOf, and discriminator-based schemas, which are not supported in our integration target. For our use case, we need fully flattened schemas with all properties explicitly defined — no $ref, no inheritance or polymorphism.

 

Has anyone faced a similar challenge? Is there a recommended way to either configure the Salesforce OpenAPI generator to avoid these constructs or post-process the output into a flat schema format? 

 

Any guidance, tools, or sample scripts would be greatly appreciated.

Thanks in advance! 

 

Best regards, 

 

Claudia

0/9000

 The Salesforce REST API supports external IDs in virtually every place Ids are used.    For a non-Salesforce developer (who is typically someone you'd create OpenAPI spec for), this is probably the only form of the REST calls they would use.   Yet you don't include them anywhere in the generated document.       Any plans to support this?     FYI - Here's a reference to the REST API Guide in case you are not familiar with how they fit into the API:  https://MyDomainName.my.salesforce.com/services/data/v63.0/sobjects/Merchandise__c/MerchandiseExtID__c/123 -H "Authorization: Bearer token"

2 respostas
  1. 3 de fev. de 2025, 15:42

    I'm asking why the OpenAPI spec doesn't document this behavior, not how the REST API works. 

0/9000

External teams calling a Salesforce API would ideally like to see the possible values for each field.   

4 respostas
  1. 31 de jan. de 2025, 23:33

    @Olajide Otolorin -Prince Your link is for the metadata API.   This is in no way related to the OpenAPI spec generated for a Salesforce org.   OpenAPI is a stand alone specification for APIs similar to WSDL for SOAP.   Please refer to this link: https://swagger.io/specification/   Salesforce generates these now  but they do not include all of the information you would expect forcing API consumers to require secondary sources of documentation.    As of Spring 25 sf is generating a skeleton spec but nothing complete enough to share with a client yet.  

0/9000

I was able to use this for a standard object(ContentVersion) and it worked fine. For the POST request it showed a lot of fields without the create() property so I had to clean it up. 

 

When I ran it for a custom object though it came back empty. I double checked that the user that was authorized has access to it.

3 respostas
  1. 13 de jan. de 2025, 23:38

    As far as I can tell, you aren't using the API properly.   There's no ability to specify which objects you want detail on as you are implying with your resources.   Instead use one of the resources specified here: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/openapi_beta.htm      For example: 

    { "resources" : ["*"]}

    or  one or more of these literal strings:

    NOTE: {blobField}, {id}, and {sObject} must be entered literally. They aren’t variables as you might expect working with an OpenAPI spec:

    { "resources" : [

    "/sobjects/{sObject}",

    "/sobjects/{sObject}/{id}",

    "/sobjects/{sObject}/deleted",

    "/sobjects/{sObject}/describe",

    "/sobjects/{sObject}/{id}/{blobField}"

    ]

    }

0/9000

Hi Team,

 

We are trying to do POC and before we do that just wanted to check if there is any tentative data for this feature to be Generally available.

 

Thanks in advance.

 

Regards,

Sushil

2 respostas
  1. 24 de jun. de 2024, 20:00

    We unable to provide a planned release at this time due to other priorities.

0/9000

Hi Community, 

we want to define one or more custom apex rest services which we want in a first step define in an open api specification. Is there a possibility to use this defined spec somehow in Salesforce to generate some parts of it, or are there any useful tips which tool to use for the definition? This will be our first approach 

1 resposta
0/9000

I've confirmed the enablement of the Beta feature in the User Interface configuration screen.

 

I'm making a request for the OAS using this command:

 

curl -vvv -H "Content-Type: text/plain" -d '{"resources" : ["*"]}' https://redacted.develop.my.salesforce.com/services/data/v61.0/async/specifications/oas3

  • `v61.0` because the docs say to specify the latest version
  • `-H "Content-Type: text/plain"` because I found another post saying it shouldn't be the default that curl sends, `Content-Type: application/x-www-form-urlencoded`
  • `-vvv` shows `POST /services/data/v61.0/async/specifications/oas3 HTTP/2`

The response is:

[{"errorCode":"NOT_FOUND","message":"The requested resource does not exist"}]

Using `v60.0` produces a different response:

[{"message":"Session expired or invalid","errorCode":"INVALID_SESSION_ID"}]

I don't know what more to try. Does the request require an `Authorization` header?

1 resposta
  1. 21 de mai. de 2024, 17:33

    Yes, your client must have been previously authenticated with your org and the OAS request include an Authorization header. 

     

    Here is a blog I co-authored showing how to authenticate to Salesforce using the OAuth Client Credentials flow.

0/9000

Hi,

Feedback has been provided in this Community for specific items; e.g. generate OAS for Apex REST endpoints.  I would like to understand the use cases you are using the Beta with.  What problem are you solving using OAS?  Why do you need OAS?  How you are using the generated OAS?  With client library generators, and if so, which ones?  To generate documentation?  To import into API clients such as Postman?  Any thoughts on the generated OAS - what do you like and don't like about it?  Please share any details you can.  If you would be more comfortable sharing privately, then please reach out to me directly.

Thanks,

Jeremy

0/9000