- Learn More
- Inbound Data APIs
- Support Expectations
Support Expectations
Support
- FAQs
- Ask the Forum
- Having trouble? Get in touch
This document contains information regarding:
- Communication mechanisms.
- What Software vendors are supposed to do as first level support.
- Scenarios to assist understand yours and our role.
- Triage actions expected of the software vendor before contacting ACC.
- Examples of error messaging and what to do.
- ACC support expectations.
Communication Mechanisms
You are to contact us using the ACC Developer Resource Centre:
- Private or commercial-in-confidence matters:
Use Contact Us
- Other matters: Use Authenticated Forums
We will notify you regards:
- Private or commercial-in-confidence matters: Email; or
- Forums: Responses, FAQs or Announcements
The Software Vendor is the First Level of Support for the User
We ask that you convey to your users that you:
- Are the initial point of contact regards user service desk requests;
- Will escalate to ACC, if appropriate; and
- Will keep the user regularly informed.
For a major incident ACC may elect to also update users through other mechanisms such as its website or an email list. This would be an additional, but equivalent, supporting message to what the software vendor will have been provided.
Who does what for these scenarios
Scenario |
Who |
Action |
---|---|---|
Receive a problem from a user Identify an ACC-related issue ACC triage |
You You ACC |
Undertake triage Advise ACC using “Contact Us” Advise & update using email &/or Forum |
Standard maintenance window Advise your users |
ACC You |
Announce through “Forum” Your standard mechanism |
Non-standard outage Advise your users |
ACC You |
As Above |
Deprecation Move to updated version |
ACC You |
As Above |
Feedback |
You |
Advise using Portal “Contact Us” |
Try the below before contacting ACC
The following is recommended to provide a quicker resolution for your users:
- Identify and review error message and attempt to resolve issue
- Has the user been set up to use API services with ACC?
- Has the authentication for this particular API product been set up correctly? (Digital Certificate / RealMe etc)
- Check local user environment – not an internet issue or network issue
- User has been configured correctly to use API products? (Switched on with ACC and IDs/numbers provided?)
- Is this a user training issue rather that technical problem? - Has the user been trained to use their system, the API, and knows what they are doing?
Please provide as much details as to your resolution steps when you contact us
Error Messaging
We recommend that software vendors set up their APIs to pass on the ACC generated error messages through to their user.
The following is a summary of response codes that a user may see, with suggested resulting action:
Code |
Indicates |
Interpretation |
Action Required of Software Vendor |
201 |
created |
Content created but not received by ACC |
Advise user to send content to ACC if still required |
202 |
accepted |
Submission received by ACC |
No action required |
400 |
invalid data |
Content being submitted is incorrect |
Confirm this is a genuine user error and not a coding issue |
401 |
authentication error |
Senders Digital Certificate is not valid so transaction can’t take place |
Software vendor needs to check Digital Certificate is installed correctly via https://secure.healthlink.net/certinfo If no issue then, contact ACC Digital Operations on 0800 222 994 option 1. |
403 |
authorisation error |
Sender is not authorised by ACC to make the submission |
User is to contact ACC Digital Operations on 0800 222 994 option 1 to arrange permission. |
500 |
internal server error |
ACC system issue |
Advise ACC Digital Operations on 0800 222 994 option 1. User needs to resubmit content to ACC later. |