finos / symphony-api-spec

Swagger definitions for Symphony LLC public REST API

symphony-api-spec

This repository contains the OpenAPI/Swagger API definition files for the Symphony REST API. The full documentation of the API is available on the developer's website.

The master branch of the repository can be used. Endpoints or attributes added in recent versions will be documented accordingly.

The main documented endpoints are:

• Pod APIs
• Agent APIs
• RSA login APIs
• Certificate login APIs
• Profile Manager APIs (using OpenAPI 3.0)
• Community Connect APIs (using OpenAPI 3.0.1)

Specifications can be split in 2 different files to separate current endpoints and deprecated ones.

A Postman collection is provided to help you test the API. You can paste the definition files into Swagger Editor, from which you can generate client code.

Contributing

The definition files are automatically updated after each Symphony release so we don't usually expect those to be manually edited. However, it can be useful to open a PR to suggest documentation changes.

1. Fork it (https://github.com/finos/symphony-api-spec/fork)
2. Create your feature branch (git checkout -b feature/fooBar)
3. Read our contribution guidelines and Community Code of Conduct
4. Commit your changes (git commit -am 'Add some fooBar')
5. Push to the branch (git push origin feature/fooBar)
6. Create a new Pull Request

NOTE: Commits and pull requests to FINOS repositories will only be accepted from those contributors with an active, executed Individual Contributor License Agreement (ICLA) with FINOS OR who are covered under an existing and active Corporate Contribution License Agreement (CCLA) executed with FINOS. Commits from individuals not covered under an ICLA or CCLA will be flagged and blocked by the FINOS Clabot tool. Please note that some CCLAs require individuals/employees to be explicitly named on the CCLA.

Need an ICLA? Unsure if you are covered under an existing CCLA? Email [email protected]

Validating your changes (requires Maven)

You can verify that your contribution is valid by simply running :

mvn clean package

This will execute the openapi-generator-maven-plugin in order to generate a Java client from the API specifications. If BUILD SUCCESS, it means that your additions are valid ! If BUILD FAILURE, check the command output where the validation error has been described.

License

Copyright 2022 Symphony LLC

Distributed under the Apache License, Version 2.0.

SPDX-License-Identifier: Apache-2.0

symphony-api-spec's Issues

Agent Deprecated API Yaml doesn't contain all the definitions found in public

For all other apis, the -public-deprecated.yml file is strictly a superset of the contents of the -public.yml file. However, this rule has recently been broken in the agent file.

/v1/message/search POST - no consumes type set

On about line 561 of agent-api-public-deprecated.yaml, there should be:

      consumes:
        - application/json

.. in order to be consistent with all the other api swagger definitions. This is causing problems for JAX-RS as it doesn't know how to marshall the body object for me.

thanks
Rob

Add Extension API swagger spec

Hello,

We would like to consume Extension API from C#, do you know where I can find the related swagger?

Thx

Presence feed not defined in POD spec 1.48

Not seeing https://rest-api.symphony.com/docs/read-presence-feed defined in spec.

Swagger Definitions

I've just raised this with Symphony support, but maybe this is this is the right place?

The V4Event specification published here: https://github.com/symphonyoss/symphony-api-spec/blob/master/agent/agent-api-public.yaml#L3821

Doesn't contain the SYMPHONYELEMENTSACTION field, and doesn't contain the object definitions to describe this payload:

"symphonyElementsAction": {
"actionStream": {
"streamId": "0YeiA-neZa1PrdHy1L82jX___pQjntU-dA"
},
"formStream": {
"streamId": "YuK1c2y2yuie6+UfQnjSPX///pQEn69idA=="
},
"formMessageId": "xtZqqBNGwLDkLuvuQTyjH3///pQENvjudA==5454",
"formId": "form_id",
"formValues": {
"action": "submit_button",
"name_01": "John",
"email_01": "[email protected]",
"country": "opt1",
"example_radio": "option_01",
"checkbox_1": "value01",
"checkbox_2": "value02",
"comment": "my comment"
}
}

Can someone take a look at the swagger definitions and update them please?

Unable to swagger-gen rc48 spec due to String model overloading

Using the deprecated rc48 POD spec and Swagger v1.5.16

Swagger generation returns errors on String model being overridden within the spec itself.

[ERROR] ..../symphony-java-api/pod/target/generated-sources/swagger/src/main/java/org/symphonyoss/symphony/pod/model/CompanyCertInfo.java:[200,17] toString() in org.symphonyoss.symphony.pod.model.CompanyCertInfo cannot override toString() in java.lang.Object
return type org.symphonyoss.symphony.pod.model.String is not compatible with java.lang.String

In spec:

String:
type: string

Availability of the 1.48 spec

When will the 1.48 spec be published?

Just concerned about the current release schedule.

Blast API sids list

According to the documentation, the list of sids for the blast API should be comma-separated. And, if the swagger looks like this:

// line 373, agent api (deprecated version)
       - name: sids
          description: A comma-separated list of Stream IDs
          in: formData
          required: true
          type: string

... all is well.

However, at the moment, the swagger seems to look for a list of strings, which doesn't appear to be supported in my version of Jersey:

       - name: sids
          description: A comma-separated list of Stream IDs
          in: formData
          required: true
          type: array
          items:
            type: string  // doesn't seem supported in Jersey?

Is this a mistake in the api, or intentional? It seems like it might be a mistake, given that the description asks for a comma-separated list.

Update spec to 1.46.3

Feature Request: Schemas

Hi,

Can someone produce a Schema for checking MessageML/PresentationML? It appears that there is a lot of checking going on in the agent code, so perhaps this exists already and can be surfaced.

Reason being, it would allow client-side checking of messages before getting them refused from the agent.

thanks,
Rob